Inherited quantites in BaseSimulation

[kubanmar]

BaseSimulation inherits from Activity, which gives it quantities that do not apply for simulations or are better specified in the schema, specifically:

• labID
• method
• location
• name
• steps
  This seems to be an indication that the parent class is not appropriate.

[JosePizarro3]

Hi @kubanmar, in my opinion, it actually means that those metadata fields are wrongly defined in Activity. I also have very strong opinions in some of those fields:

• labID is clearly not general enough to be considered part of any generic activity
• method is a hacky way that they had for storing a string defining the method used in the activity, but definitely it should be reworked in something similar to our ModelMethod (ideally, there should be a Method class from which our ModelMethod should inherit)
• location should be deleted. Definitely, the location in which an activity is performed, from the perspective of reproducing a scientific activity, is not needed (at least not from the Materials Science perspective). There might be cases where this is not true because environmental conditions are important (e.g., traffic nearby producing vibrations, weather, etc), but not in all activity cases. It is also typically a pain to fill such field when there is no need...
• name and steps are indeed part of Activity. There are more, like start_time and finish_time

Maybe it is time to have a chat with @hampusnasstrom about this :-)

[hampusnasstrom]

Let's have a discussion about it.

• lab_id is still valid but has a confusing name (coined by Markus Scheidgen). It's not the ID of the lab but the ID of this activity which is used within the lab/inststitute. This is used heavily to give a more readable identifier than the entry_id and we have special sections that automatically resolve based on this.
• method was something used before the data section was searchable and is less needed now. However, it does give the possibility to filter activities in a very abstract way so I don't mind keeping it there
• location I completely disagree with @JosePizarro3, I think it's one of the easiest metadata to fill (typically with a default in the lab specific plugin) that can provide a lot of information after the fact. I do appreciate that it's a bit vague for computations but isn't it interesting to know at what HPC the calculation was done?

We are currnetly working with @JFRudzinski, @EBB2675, and @amirgolp on the basesections.v2 so this would be a good discussion to have there.

[kubanmar]

I'm not sure if we have the discussion here, or not, but my questions are more concerning the practical aspect, i.e., I'm not sure if it makes sense for us to populate them (because of mismatch or redundancy), and if so, how would we do that, e.g., during normalization, parsed, from tabulated data, or else? Let me be more concrete:

• I think I see what you mean by lab_id, but how does it apply for a simulation? Are the groups uploading their calculations to NOMAD meant to give each code they use some ID? If not, do we provide a template for that?
• We are much more specific about the method in our model_method section. Should we, instead of populating model_method, add it to general method section?
• It would be useful to have the location set, but I don't think most code output provides this information. We do have something similar, i.e., compilation_host, but that is not always linked to a "physical" location.
• I'm not sure what to put for name either. Do we just put something like "Calculation", or are the users supposed to provide it? How do they do that if they upload many (e.g., 100, 1000, ...) calculations at once?
• We provide steps in the workflow and workflow2 sections. Should the steps in activity just reference to it?

These are just examples, but I think we should consider these points when deciding the base schema.

[hampusnasstrom]

We had some discussions and one suggestion would be:

• method becomes a subsection BaseMethod which contains name, type, and external_reference. This can then be inherited by the BaseModelMethod: https://github.com/nomad-coe/nomad-simulations/blob/develop/src/nomad_simulations/schema_packages/model_method.py#L18
• Similarly the location could be a BaseLocation subsection that for simulation is specialized with cluster information and for experiemnts is specialized with physical location in the world
• datetime_end can be move up from BaseSimulation to Activity: https://github.com/nomad-coe/nomad-simulations/blob/develop/src/nomad_simulations/schema_packages/general.py#L118
• steps is still unclear. We might need to move this to the more applied experimental sections or link to the workflow2 steps.