 adequately constructing one-year functions and in fact some of some of the work that I'll talk about here was actually the support of that project basically doing some of the IO for hacking away at some of the one year 90 data. So my research interest currently, as I'm working in industry are related to materials for infrared sensing applications. So both conventional materials, but then also looking at possible applications of 2D materials in this field. My primary role is optical opto optoelectronic device design so modeling and simulation of device performance. And then of course as a hobby, FOS development is something I'm interested in. In fact, that's the capacity that I'm kind of here today. So I think that you might be able to connect on some of these platforms. If these are published in PDF, then these will be links that we can probably follow. So maybe just a quick motivation so as we all know one year 90 is basically the go to package for constructing maximally localized one year functions and Python, as I would argue is basically the de facto standard programming language high level programming language for applications having many, you know, high quality numerical libraries NumPy and SciPy are just some examples. And there's many tools of course related to one year functions that leverage the Python programming language so a couple of them were discussed during the summer school as I understand. I ate a one year 90 I'm listing them here. Z two pack one year Barry Python type binding. These are just a subset of what I imagine is available so one of the issues I think that was, you know, discovered and discussed already is that there's really no official standalone package for doing one year 90 IO and Python standalone and I make a specific point about that because of course there's many routines that people have implemented in these codes, but they haven't necessarily been put into a single kind of common unified package and I think that that's essentially what we're trying to discuss and do here this week. Let me just kind of go through the purpose of essentially what we're trying to do and, and one of the first steps really is just to kind of establish a repository for such a package, a place that people can contribute and put routines that they may have already written for the purpose of one year 90 IO, and then also identify collaborators, both in like a formal sense collaborators on GitHub, and of course in the informal sense those he may want to contribute to the package. So there's also an attempt to consolidate some of the existing IO routines as I mentioned there's many of them already out there for parsing the input files or reading the data files. So can we get those into a common place, and then actually sit down and, you know, think hard in some sense about what this API might look like to support not only the current IO needs but also those that we might expect to be needs in the future. And then hopefully we'll be able to actually put together development roadmap, you know, what's some of the long term development. And so on the right hand side just kind of showing, you know how this might look like structurally it's just rather simple and, you know, of course one year 90 is at the base of this kind of hierarchy, maybe DFT below that but one or 90 can you know create all the the one year functions and has a lot of data, both inputs and outputs, and this is meant to be a layer between that and tools written Python that depend on it only in iOS and so these are not built on top of it. In, like, in any manner but really just the IO. So I highlight some of the routines or functionality that might be available in this package. You know parsing the files I bold those because those are ones we've actually done so far. And then of course you know maybe writing the, excuse me writing the wind file should you be interested in, you know, doing this in a high situation, and then reading some of the data files to these ag files AMNs MMNs. These are some of the things we have in mind. So the approach I think is rather simple to start basically coming up with some really just simple text parser so being able to take the file contents of a wind file, or NNKP file and be able to parse it into a usable structure Python data structure like a dictionary or NumPy arrays, for example. And then also, I think it's important to establish what the architecture would look like for reading the AMN MMN I files. I mean it may not just be as simple as parsing into array, especially if you're working in a situation where you need to do this in parallel. These files very large you may not be able to fit them all in memory. How do you have a, you know, a functionality that enables you to do that. Do you read from file, do you need to be able to read from a stream of bytes for example so these are things to consider. Some of the stretch goals here, in addition what I just mentioned would be to actually publish this on PyPy I mean that would be a pretty big milestone so packages can pip install this for example, you know, just install the package. I kind of had a couple other thoughts in terms of using F2Py or F90wrap to wrap the library functionality that Jerome discussed as a possibility of kind of getting some of this interface for free. And I think that's going to be the subject of some discussion during the working groups. Yes, and unfortunately I can't really claim the first bullet point yet there's something I'll do this morning is actually creating the repository of course I have one, you know local to my computer, not very useful to everyone else but you know we should create this repository on GitHub it has a very robotic very high sounding name you know one year like 90 PyLibio this is something that we of course could change, and hopefully we'll, you know, through discussion with Giovanni and other developers maybe move this to the one year developers organization. That would, I think be a, you know, a desirable end state or end place for this to be. I implemented some parsers for the win files and then KP files, and I'll kind of show you an example of what that looks like. And, you know, currently just parses the file contents as I kind of imagine so users kind of responsible for opening the file reading, you know the string basically and it can be parsed into a dictionary or in some cases some of the objects are dump high arrays, like K points for example it's natural to express like that. So I kind of alluded to this I already have some implementations again, among many others and other codes for reading the other data files I files and projection matrices and so on. In another package that is in some sense the fun that I haven't really contributed much there but you know after we discussed the API this maybe there may be some opportunity to kind of copy that over. So this is a bit of an eye chart it's just kind of discussing a little bit of the package structure I mean, and some says invitation to you to, you know, look at at the structure and see where you might be able to fit in, you know some of these pieces. And it kind of leverages a pretty standard, you know, Python package structure with, you know, different directories for the source that has a test suite documentation, and then a variety of like kind of repository configuration files for doing the automated continuous integration through GitHub workflows. I, in fact, was the one who implemented that in one year 90, the base code, doing the testing through GitHub action so as an example of that, if I don't know if I can kind of like this but in this link. There's pre commit check so you know, a lot of the work that's been done is actually kind of putting the machinery in place to allow other developers to contribute and be part of a kind of, you know, a robust package. So a couple other points maybe to make here is the documentation is done with make docs is kind of a cool documentation generating thing that uses markdown basically like Sphinx but markdown instead of restructure text if you're familiar with that. And then testing with pie test again another standard tool basically in this ecosystem for for doing testing. I'm fortunate I imagine this is a bit small to read so I'll just kind of read it in some sense here that there are some considerations to be made so this discussion basically started in an issue on aida one year 90, or there was the no, you know, notice that it would be nice to have this tool available a package for doing the one year 90 IO, but the existing one that I had written for example, red files, and for I had a one year 90. It really needed, it didn't have access to file system so needed to be able to read from a stream for example. And so it's kind of highlighted in this issue and so you know something that needs to be taken into consideration when developing these is making these projects, except the kind of large variety of inputs files file handles, byte streams, and, you know, be able to do things iteratively instead of all at once. And on the right hand side is just a couple examples of the signatures of the parsing parsing routines. So as I kind of mentioned before, you know, large part of this is, you know, the machinery to enable kind of future development. So I have just just a couple expansion on a couple of the tools. Again, this is a bit of an I chart, you know the documentation with make docs uses a very popular UI library called materials that makes these very in my opinion, very clean, nice looking technical documentation and you kind of get the a lot of the niceties for free. And all you have to do is write markdown so something that everyone probably can pick up quickly or already knows. And then on the testing side, actually have established a test suite that basically can pull down all the versions, build executables and this is meant to be done in a continuous integration environment on a, on a particular architecture so we know what it looks like. And then the routines basically go and parse all the wind files parse all the NNPP files and make sure there's no exceptions, fairly standard tests. And of course, other tests can be added to this, especially if you want to test, you know, proper reading of the data files. For example, output of, you know, the testing the NNPP parsing and wind parsing, and it looks duplicated because that's different one year version so at this stage it kind of passes the test suite for these versions and this can check for like backwards compatibility or for its compatibility is new versions are released. So I kind of want to touch a little bit on the core functionality. And it's largely related to regular expressions and kind of pattern matching because we're talking mostly about parsing the text file in the wind. So there's, you know, the concept of, you know, parameters blocks comments and then we have regular expressions that know how to match these kind of three, you know, categories of textual components of a wind file or even and so this is kind of like the core module and then we have a variety of kind of like low level routines for extracting all the comments extracting all the parameters extracting the blocks, and then given a list of the blocks you can kind of further process them and say what does a K points block look like what does a unit cell block look like, and kind of, you know, in some sense unpack the information in there so turning a K points block into an array of, you know, and K points by three. It would be one example. I also put together a CLI to a command line tool that's essentially meant to be used as a development tool. So something that you can from the command line say parse me the wind file, and it'll print to the screen, the Python dictionary that represents that wind file and you can, you know, inspect and make sure the parameters look right. You can even ask it to say well, you know, parse me this particular parameter parse me that particular block and inspect it to make sure the parsing is done properly. But also there's an opportunity to adapt this to make conversions. I think Giovanni mentioned this like JSON files, imagine you want to convert a wind file into a JSON file to be used in like a web based environment so that that would be one option, or I think the discussion recently is, can you convert this to an HDF file, HDFI file, and be able to use this and like a parallel IO type application. This could be adapted or hacked in some sense to do that. But this is very busy. I think the color scheme is the main thing to pay attention to so on the left hand side I have an example of a wind file this the gallon arsenide example. And you know the different components as I kind of alluded to the, the comments the parameters the blocks are in different colors. And on the right hand side is the parsed wind file. And you can see that there's a variety of keys there's a key for the blocks that actually has the text of the blocks extracted. So the text for the comments. Now fortunately these aren't like kept in any particular order. The comments is probably not all that useful. The blocks is mainly just to kind of get it all in a text format. And on the right hand side of that panel is is really the important pieces that the parameters it's just a dictionary of parameter value pairs. The blocks themselves have been broken down into kind of different structures so that Adam's block the unit cell block the K points block are part of that structure as well so this is essentially what you would get if you said you know parse me the contents of a wind file. This is the structure that you get out. So the next steps I think and next steps meaning like you know what we might hope to accomplish, you know during the rest of this week is, you know some more bookkeeping type things you know, we need to figure out what the licensing would look like, you know, again this is somewhat of a silly name for the for the library a bit robotic so you know can we come up with something that's a little bit more interesting sounding. Of course maybe a large committee like this is going to yield something that'll be maybe difficult to do but discuss potentially moving this to the one year developers organization, I find that to be probably the most natural home. And then there's an opportunity to kind of fill out other areas of the repository that the read me the documentation is all kind of like bare bones, you know just a skeleton of what it would, what it would look like, didn't want to invest too much time, when it's probably going to be in flux early on. And then you have some other items like a contributor's guide and code of conduct, kind of boilerplate stuff. And then I think the primary thing to do is really sit down and think hard about what the API would look like for reading the data files I think the, the win and then I'll go straight forward but the, the matrices UNK files and I didn't include on here but like checkpoint files. You had mentioned you know that that would be worth reading the actual portrait files as well. So there's a couple issues related to this and I just highlight some of them here related to parsing in particular so you know the discussion of different field sizes to make sure that you don't have, you know fields kind of running into each other and if you're going to split on a space where you can't have two fields, the numbers budding up so that's there's links to these issues. One of them I think I've had some discussion with Jonathan on GitHub is, you know how the actual bands and there's this new feature called select projections that was released in 3.1, you know these integer ranges how you actually define those and there's a little ambiguity is you know using commas and spaces and semicolons all as list. You know delimiters, you know we might need to clean that up a little bit to make parsing a little bit easier in terms of not needing a bunch of kind of gymnastics to kind of get it to work correctly so this is something that we can talk about. So yeah just kind of enclosing you know I'm of course interested in working on other projects. As you might imagine, you know the development tooling is kind of a thing of mine I contribute to several projects that it was really just like doing GitHub actions you know because I kind of got a hankering for that so I'd be happy to work with other projects and kind of put some of this type of know how in there. Should that be useful. And yeah happy coding. Thanks. I've got any questions. Okay. I'll start from the closest one from the nearest neighbor. It's more like a comment thanks a lot already for the work you did. Maybe personally I need to discuss what I think putting in many developers is a good idea. I think the important thing to discuss is probably understanding who wants to be a maintainer of it. Because I guess this might require a bit little work probably not too much and I think it's important to even to see who wants to contribute already now maybe you already have everything in the end. But maybe also who can maintain it in the midterm at least. I'm happy to be involved. I won't be able to do it myself alone but if you're there maybe someone else can help. Not it's a good point I think there's, you know, opportunity for someone to take responsibility I think that this is something I could probably, you know, push forward early on but of course we would need other people to be there as well I think there's been in the GitHub discussions I think there's been a couple people that have said, you know I can contribute here I just can't be the driver. So I'm happy to help drive it and then you know of course getting support from others. I don't understand what is the stage now so basically you have only the wind file now reading the writing, but not the amn chk that you don't have now right. So, yeah, that's this kind of two pieces so one of them was a package I'd written several years ago that has all of what you mentioned so reading the am I checkpoint un case, but it was done by an older me who knew very little compared to now. So, I think there's an opportunity to copy some of that into this kind of new kind of somewhat from scratch with the understanding that I can talk with you and others to see what that API would look like. Maybe the function signature changes but some of the guts of the routines that were written previously can be copied over. I mean for reading the checkpoint pop, for example, it's just not present in this particular repository, kind of pending, you know, understanding from the other codes. What should the routine interface actually look like. And hopefully that's our most of this. So, so I just have a suggestion so like you talked about testing right so you know how do you make sure that when you read the wind file. It's read in the same way that money and 90 would be dead. And I'm thinking maybe like as a part of the testing you could have like f2p interface for some of the money and 90 routines. And then you kind of run your own routine, read the object, and then use the actual routine from money and 90 to f2p and see what does that function, you know, and then make sure that you know they kind of read things consistently. And I think sometimes in these files and, you know, like, you know, as you said, there are multiple ways to specify something, you know, like the column, comma, you know, have the indices. And you know, so you know, maybe that's a way to kind of cross check that you're kind of reading in things well or something. And the point we've done a little bit of this in the sense that we can parse the wind file, and then pre process the wind file to get the NNKP file, then read the NNKP file and then cross check things like exclude bands k points and then even the projection so you can read the projections like sp3 and then look at the NNKP file and it has it in the MRL representation, and then check that those agree so you can't do it for all the inputs but you can do for a subset but yeah, it would be good to check with the actual 410 routines themselves. Thanks. Other questions. Online on zoom. So if not, let's thank you again. Okay, so this was the last talk for this morning. Now we have, you know, quite some time for free discussions and coding, if you wish. But before that, maybe Giovanni and Roksana, we sort of make groups like yesterday afternoon and then we leave everyone free to work on what they prefer. So there is, yeah, so there is one group that emerged this morning is this pw2190, where I listed the Junfeng, Giovanni and Jmo. Is there anyone else who'd like to be assigned to this group? Raise your hand, otherwise Valerian? I don't know, who wants to be in charge. Thank you. Thank you. I think yesterday there was quite a demand for the group on the other corner. Okay, Roksana will be in the hand. Okay. Whatever. You think it will be too broad? Okay, okay, your name? Giovanni. Giovanni, like Giovanni. But with a different surname. Maybe a comment for those who are connected online, if you can hear me. So, unfortunately, it's a little bit complicated to interact with you online, but what we can do is that you look at the groups that are being written on the Blackboard. If you want to interact with one of those groups, you contact the person who's in charge of that group, the one that we circle, and then the group decides how to do it if you want to have it on Zoom or not.