01.11.2023 Area A Data Modeling

[hampusnasstrom]

Agenda

We will discuss the System base section. More detailed agenda to follow.

Meeting Notes

Attendees: @hampusnasstrom, @aalbino2, @JFRudzinski, @JosePizarro3, @lauri-codes

• In area A we have so far had one entry per unit that needs a result section
• In area C the system is nested in one entry which could even be in some run entry
• We should not worry too much about how to find the data in result at the moment

Tasks

• We should come up with examples for individual and shared use cases

[JosePizarro3]

Some examples from my side:

1. An isolated atom Zn.
2. An isolated molecule H2O.
3. A crystalline bulk Si2.
4. A solution of C100H400Cu
5. Heterostructure Au/G (G is Graphene)
6. Passivated surface TiO2-CO2
7. The combination of 5 and 6, Au/(G-CO2), passivated graphene on top of gold.
8. A carbon nanotube connecting two metallic materials.
9. A vacancy/defect in a specific position of bulk Si2.
10. An active (active in the sense of emission, e.g., XAS) atom in bulk Si2.

[ndaelman-hu]

5. Passivated surface TiO2-CO2

7. The combination of 5 and 6, Au/(G-CO2), passivated graphene on top of gold.

Regarding the passivated surfaces, what would these exactly be at the atomistic level?

• Do you mean that the CO2 is physisorbed or chemisorbed? On that point, do we want to distinguish both adsorption modes?
• Or maybe you meant passivation as in the synthesis step used in semi-conductor physics to reduce carrier recombination (though I think electro-polymers are more appropriate here than CO2)? This would also be an interesting test case, as I imagine that at the atomistic scale this system can become tough to model, with various surface reconstructions and multiple kinds of dopants / adsorbates. In how far can we bridge synthesis and computation in this case?

[JosePizarro3]

You can extend the example. Does physisorbed and chemisorbed implied something at the system level? I was thinking more on having GaAs and a molecule of CO2 at a given moment in time on top of it, not about the time evolution (we are looking to define Entity at the end of the day).

With respect to time evolution of the molecule on top of GaAs, we have to decide: does each snapshot deserve its own entry in NOMAD, or should it be simply a list of Systems?

[ndaelman-hu]

I was thinking more on having GaAs and a molecule of CO2 at a given moment in time on top of it

You're already thinking 2 steps ahead, haha. I'm still stuck on seeing if we want / can capture the distinction between physisorbed or chemisorbed states. They are often approximated as intermediates, especially the latter. I'm unsure if the distinction makes much sense at the synthesis level, maybe more so in some experimental characterization setups.

Regarding your question about time evolution, I know of people who indeed use MD to model molecular beams scattering or sticking. I'm not sure whether they make such a strong distinction between physisorbed or chemisorbed (i.e. sticking). I think they're more so interested in the angular/momentum-resolved scattering channels.

Anyhow, guess these are additional examples for next week.

[JosePizarro3]

What I meant is that I put examples which are independent of the time evolution. For a system evolving I think we should still divide them in entries OR keep them as a system list.

As I see it, if it is physisorbed or chemisorbed it is just a matter of another tag (something like is_molecule_absorbed maybe?), rather than the base class structure itself.

[JFRudzinski]

Here are some more examples maybe worth considering:

11. Ti-6Al-4V alloy with volume fractions 0.8 BCC and 0.2 HEX phases

• Grain-scale spatial model for simulations can be built from electron backscatter diffraction
• Need to describe interface between phases, e.g., defects, dislocations, disconnections
  
  PAPER

12. Statistical (continuum) model of Al-Al2Cu
    
    PAPER

13. Heterogenoues 3D reconstructions from atom probe tomography
    

14. Synthesis, experimental characterization, and electronic properties modeling of 2D perovskite transistor
    
    
    PAPER

15. Multiscale workflow for OLED design
    

[JosePizarro3]

Maybe we can also share a Google Slides document where we can see the basic structures and modify with suggestions? I have the feeling this is the only way of giving and writing down feedback for the datamodel.

[JosePizarro3]

https://docs.google.com/presentation/d/1fjgRpjE_u90S_ddpp-IJ8A9Z2ScZRav_nMMARwFNGc4/edit?usp=sharing

[ndaelman-hu]

Thx! I added some small questions / feedback as comments.

So, just to understand your vision: all the Particles that make up the entire system are stored together, yes? They are then used to specify substructures of the Topology at various levels? Symmetry can be either used to a) describe the structure at large, as well as b) various topologies. I'm not sure why it should also be connected to c) the Particles again.

Is this the correct way to interpret your design?

[JosePizarro3]

Hi, I haven't yet added the final schema to the Google slides. I simply resolved your comments, as some might be resolved through the new structure.

Now, I added my tentative schema (in slide 4), and I will work in the examples shared from @JFRudzinski @hampusnasstrom @JosePizarro3 and the comments by you (@ndaelman-hu) and @mkuehbach in slides 5 to infinity.

I will come back later to this Discussion to announce it 🙂

[mkuehbach]

Very valuable to see what is discussed here, looking forward to discussing with you at the project meeting about this.
The essence of the discussion which I had today with @JFRudzinski is summarized in @JFRudzinski screenshots (shown above)
There is a substantial overlap in terms of how to describe features/components of a system at different length and time scales, from what I read here, we have already many examples, in my opinion too many to practically deal with thus we should answer first:

What is say maximum one very clear example at a given or in between scales (length and time) example for each area?
What is the expected outcome of this effort?
Initial work on the structural description must not be ignored:
https://fairmat-nfdi.github.io/nexus-fairmat-proposal/9636feecb79bb32b828b1a9804269573256d7696/cgms-structure.html
On the matter of how to organize time and space my proposal is as follows: do the static description (i.e. the system at one timestamp right,
then consider time as a set of snapshots, naturally a set of such snapshots needs anyhow processing to arrive at trajectories where the
processing is nothing but building and computing a logical relation between states of features along the time axis, also here
https://fairmat-nfdi.github.io/nexus-fairmat-proposal/9636feecb79bb32b828b1a9804269573256d7696/classes/contributed_definitions/NXms_score_results.html#nxms-score-results shows a concrete example for a mean-field computer simulation tracking states of an interface network along discrete simulation time steps (see NXms_snapshot_set)
NXms is essential NXmicrostructure or making it broader NXsystem, if you do not like the NX drop it but the idea remains close to what you consider.
Also some sub-areas from Area E should be involved, (it seems weird that we at all always ask others for example, area E is the dedicated team for our examples).
I see NeXus can take some role here although at this point I would not at all insist on blocking our mind with doing it exclusively one way or another. The point is we have to understand what our points of view are and how base classes and NeXus can come possibly beneficially together here. Also forget about how to serialize information right now, i.e. whether in json or HDF5 it does not matter at this stage.
It should be some graph description a graph whose nodes eventually may end up in some cases maybe in metainfo or base section and other nodes of which just point to containers (such as HDF5 or ZARR) where the really large number and arrays with indices are stored in as for these use case I see there is currently not a clear use case how to do this in nomad at all and I would be really careful with storing too much in plain json but rather think hard about in which case does pointing to some other place and loading from there makes sense.

[ndaelman-hu]

On the matter of how to organize time and space my proposal is as follows: do the static description (i.e. the system at one timestamp right,
then consider time as a set of snapshots, naturally a set of such snapshots needs anyhow processing to arrive at trajectories where the
processing is nothing but building and computing a logical relation between states of features along the time axis

Very reasonable, but do we need the time series stored in a single entry or separated by time. I guess this heavily depends on the no. snapshots.

[ndaelman-hu]

It should be some graph description a graph whose nodes eventually may end up in some cases maybe in metainfo or base section and other nodes of which just point to containers (such as HDF5 or ZARR)

What do you mean here? Should the visualization be graph-like, the query formatting, or the data structure. One does not necessarily entail the other.

[mkuehbach]

Also we need to ask ourselves questions like what do we aim to search for, what does it mean when we talk we would like to search for structures.

[hampusnasstrom]

Very good point Markus, thank you for your input!

[hampusnasstrom]

One complex example from area A/E (but one that is already partly realized in NOMAD) would be a thin film solar cell with amorphous, (mono-, and poly-) crystalline, and monolayer components working together as a device due to bulk and interface properties.

Source: https://doi.org/10.1126/science.abn8910

[mkuehbach]

Indeed a very nice example. In terms of priority would it be more important to know the general layer on the left hand side or be able store exactly where physically that image B was taken in the coordinate system of the large sample that is shown schematically in A?

[hampusnasstrom]

I would say that in this specific case the general layer on the left is what is important.

[mkuehbach]

Thanks @hampusnasstrom indeed I can confirm that e.g. for EBSD it is the same issue, you have a very easy time to harmonize different representations when you demand only the pixel coordinates, you have a harder time already if you would like to get calibrated pixel coordinates i.e. how long is a pixel, you have right now de facto no chance (tested this with 5 tech partners) to get the actual position i.e. calibrated pixel coordinates + offset where this is on the sample,

[JosePizarro3]

Thanks @JFRudzinski @hampusnasstrom for the examples, and thanks @mkuehbach for getting involved 🙂

I've been working a bit on the schema, but rather in a piece of paper and trying to see whether it covers all the examples I and Joseph shared (I'll also try to see whether Hampus' one and the comment on time evolution by Markus can be included). I will push something tomorrow, so we can maybe talk about it during the project meeting.

Just to let you know in advance, I think we have to agree on how to divide entries in NOMAD. There will be cases where this is possible, and then, an extra entry has to be created to collect all the systems, while in some other cases it will not be automatically possible. This is something we are doing already regarding methodological workflows (like MD, GW, BSE...), so I'd say if we integrate this into System it will work and it will be good for searchability and findability of different samples.

Now, where exactly in System to put this information is what I will share tomorrow. I think we can nest groups when an entry refers to a set or collection of systems, and regarding time evolution, System can be a list in which each element will refer to a time step t. But again, let me work on it and tomorrow (or a bit later during the weekend) I send the schema and how all the different examples can be allocated within.

And also, feel free to keep sharing stuff. This is really valuable! 😄

[aalbino2]

Thank Chema, sounds good to check out what you will show.

Making System a list is good. I leave some comments focusing only on one single snapshot in time. As stated last time we met, we should support the parts composing a system to be separate entries or just to be composed objects in the same entry.
Lauri was saying that in the topology section the parts are labeled and made searchable through these lables, we should exploit this labeling mechanism for composed object, while for the separate entry case, they are searchable already. We should harmonize the topology structure with the components list appearing in the baseclasses, this means that the set of available labels and the set of available classes should be isomorph sets

[mkuehbach]

This "letting the GUI pick up and walk along a chain of identifiers for things (objects, features, class instance etc) is exactly the idea of topology and that is carried through in the design of NXms_feature_set which is de facto a proposal how to generalize the idea of the topology of nested point set to more complex nested sets of different geometric primitives - in plain language a hierarchy of e.g. triangle meshes or polylines sets and voila you have a description for samples and its layers at the macroscale or microstructural features whose location and "shape" morphology is discretized using computational geometry. The key question to me is what do we expect the GUI to expose in this case.
Searching is one important aspect: I can easily imagine the request you want to search for features with particular descriptor value range, e.. show me all the dataset which have an interface/grain boundary in it that belongs to the say Sigma something family but before getting such specific we should address for which specific examples we want to implement this after the discussion about how to have a general structure (@JosePizarro3) has been dealt with

[ndaelman-hu]

So to keep adding to the list of use cases:

• We should be able to denote charged systems down to the atomic level (oxidation states are also fine, but are just a derived property). This would be going beyond the view of just geometry. In practice, such charged atoms can come from chemical reactions, capacitance, or incident light / electron beams (PES, XPS, or TEM). To this effect, we might want to revise the scope of label. This came out of a discussion with @JosePizarro3 today.
• Mentioning beams, should these be part of the system? @mkuehbach How is this modeled in Nexus? I guess from a computational view, one could make the case, but from an experimental one it seems less likely.
• Haven't seen nanoparticles (NP) yet. Here one should be able to find them via multiple surface indices, as well as "radius".
• Layered alloy NPs: these are known to invert (i.e. they turn inside-out) upon heating.
• Ensembles: these are systems that in and of themselves cannot be represented as a single geometric structure. They are temporally changing, but most of their properties can be derived using a (Canonical) partition function.
• Spin-waves? Maybe @JosePizarro3 wants to add something here.

[mkuehbach]

@ndaelman-hu: modelling beams is currently a discussion how to do it with NeXus. While no decisions have been made on how specifically to serialize the description of beams it is already quite clear that we will use the NeXus base classes to explicitly detail coordinate systems and all their conventions, use affine transformation to help locate objects in these coordinate system (components of real or virtual/simulated instruments), beam descriptions will likely follow a raytracing approach where you are able to follow and walk along the path points the beam illuminates and make specific statements about the state of the beam i.e. measurements or simulated results of the beam's state. We clearly will draw a boundary over which we would not like to overmodel specifically when it comes to how to serialize some of this scene descriptions as for this established software tools and standards in the graphics, computer aided design, and VFX modeling community are available. Primarily to avoid reimplementing their functionalities. Personally I am very much a fan of using Blender in nomad to display these scenes but it is also true that of the many topics to my heart in interest I have to prioritize and here is where currently my priority is on enabling the injection of standardized data into nomad using foremost NeXus and specifically for examples of EM, atom probe as well as continuum-scale modelling at the interface to our engineering friends

[mkuehbach]

@ndaelman-hu indeed charge should be considered, for sets of tensorial state variable values on discretized fields some classes in NeXus are available already adding k-space grids as a special type of tessellations namely tessellations of k-space rather than real space one can build on already existent work and here I argue the NeXus base classes are well equipped already and the system base class could provide the additional logical/semantic sugar tagging and contextualizing these lower-level building blocks. Indeed @JosePizarro3 there is more than the mere geometry (with primitives) also with tamas I discuss a while ago and we came to the agreement that the descriptive power could be improved with including complex like from fuzzy set / "fuzzy geometry" probability density fields these are typically samples/evaluated though on grids, as I think is also often the case in many abinitio tools evaluating again that on grids and thus the desxcriptions end up on a grid just not maybe the much simpler grids in real space I use as an engineer.

[JosePizarro3]

Hi all,

Once more, I am currently working on the schema. As such, I decided to limit the role of the people visiting the Google Slides to viewer. I wanted to give a few comments before discussing how to continue after working out the examples (specially for @ndaelman-hu and @mkuehbach who have not been present the last meeting).

The idea here was just to give some examples and try to define a System schema which can handle such situations. From this, one can build much more complicated cases and extend the metainfo at will. This is because one can find effectively an infinite number of examples, but working without the schema in mind makes it rather impossible. This is why I capped the interactions with the Google Slides until we make another meeting.

Said so, we haven't talk about data storage and breaking System into entries. This is because, as I see it, each area -> task -> domain expert can decide what is beneficial for them; just to give an example, MD calculations won't divide entries per time step, but Area A synthesis methods would like to (maybe?). In my mind, with the schema and examples at hand, we can live it flexible so everyone can decide. And furthermore: we haven't discussed the role of System vs Method and the intricacies herein yet. But again, if the System schema is flexible enough, this allows for room to change. But here there is something to discuss but I wouldn't like to give my thoughts yet in a Github discussion, but rather sit and discuss somewhere next week.

@hampusnasstrom @JFRudzinski @aalbino2 can we allocate some time for it during next week (1-2 hours)? If so, I would be happy to have a full consistent schema after such meeting. I will let you know once the Google slides are finished and open again the role to editors.

[mkuehbach]

Indeed I might not have commented on the slides if I would have been in the loop in the first place to get the contextualization that is around the aim of the specific discussion to seed a more general description of "what is a system" and how to model it in "nomad".
Indeed what is considered the set of pieces of information referred to as an "entry" is a matter of interpretation and maybe a good exercise in the first place would be to check whether we would learn from each other what we understand an entry as such.
Nomad in the end assigns a given set of piece of information a set of tags or grouping better to say which constitutes the idea behind what is an upload how is it different from an entry how is different from a file how is it different from a given metainfo section.
I agree the discussion about how to serialize information (is a separate one and should be discussed separately).
Nomad metainfo is schema with controlled vocabulary terms behind which specific information is stored
I assume we here discuss that we would like to extend such a schema of controlled concepts and controlled and named places for storing instances of such concepts (i.e. numbers, array, scalar, categorical info).
One fact to this is that many of such concepts have already been defined and are already part of nomad via the nexus section so they should be taken advantage of instead of having again every domain expert reimplementing the wheel and doing so in nomad
Noteworthy to mention is also that currently the fact that part of the nomad metainfo is archived (i.e. serialized as binary JSON files with the same name) demands that one has to be very careful with figuring out whether people would like to map their assumed concepts in instance sections or whether they talk at the concept level, i.e. are you talking about the A- or the T-box of your nomad metainfo ontology?

[JosePizarro3]

Hello (again 😄),

You can now take a look into the Slides. I tried to add all the examples you had and shared what a schema under System with the base classes as defined in slide 2 would look like. Of course, these are not complete, and I am expecting more feedback. You can also find a slide with more general comments from my side in slide 3.

In any case, I would like to point that, on a practice level, all the examples have been covered one way or another by the schema. By the way:

• For Area A people: this is nothing but CompositeSystem but with more quantities defined to integrate the topology and symmetry.
• For Area C people: what I did was to remove AtomsGroup and directly nest System on itself by adding a couple of quantities, topology_index and entity_indices.

Please, feel free to give feedback. I am pretty confident I was biased towards computational calculations in some situations, and more specifically, to materials-based computations.

Have a nice weekend and see you all next week in person 😉

[JFRudzinski]

Ok, we are thinking to start around 9 am tomorrow and work through the morning session if needed, in room 1.108. Please confirm or state objections / alternatives.

[JosePizarro3]

Hi, I am planning to talk with Florian and Lukas about interoperability in the morning too. Maybe I can meet with them at 9am and we meet at 9:40-10:00am we meet for the base sections? Let me know if it is ok, and then I move the meeting with Florian and Lukas (we initially discussed at 10, but I prefer to leave a long 2 hours empty to discuss about base sections).

[JFRudzinski]

I think that will work fine. I think also that some of us (e.g., @mkuehbach and I ++) could start preliminary discussions about the microstructure descriptions already at 9am and then update you when you arrive and slower move to the base sections discussion. But given the train strike, I may need a little more time to arrive in the morning anyway.

[JosePizarro3]

Ok for me. I will join as soon as I finish, around 10am. I think because of the strike might make more sense to stay at home for me tomorrow, but let's see.

[mkuehbach]

I second @JFRudzinski suggestion, will be there tomorrow 9am

[JFRudzinski]

Hi Everyone. I would like to suggest that we meet sometime this week (at minimum @hampusnasstrom, @mkuehbach, and @JosePizarro3) to continue our discussion from last week by walking through Chema's examples + whatever additional examples each person would like to bring, according to the schema on Chema's slides.

@hampusnasstrom should we use the Area A data modeling spot for this or do you have another agenda there? I suggest Wed in any case. I am completely open/flexible on Wed atm.

[mkuehbach]

For whatever spot you decide please drop me the link, I unfortunately have to cure from a Covid19 infection, fever is down but will need a few more days at reduced speed before I join full speed again

[hampusnasstrom]

Let's use the Data Modeling meeting tomorrow at 10:00 for this.

[JFRudzinski]

Great, thanks @hampusnasstrom!

[ndaelman-hu]

A couple of examples came up that have quite been addressed yet. I'll see to join the meeting today. If necessary / wishful, I can add them to the list later on.