search

simphony / simphony-metadata

[LEGACY] This repository contains the metadata definitions used in SimPhoNy project.
BSD 2-Clause "Simplified" License
0 stars 0 forks source link

New CUBA keywords to represent the modelingEngines #12

Closed roigcarlo closed 8 years ago

roigcarlo commented 8 years ago

We need new CUBA keywords to represent the different modeling Engines (OpenFoam, nCad, ...)

kemattil commented 8 years ago

Is that really necessary?

I currently think that the names of the modelling engines do not belong to the CUBA keywords ...

kemattil commented 8 years ago

Or did you mean that there should be CUBA.MODELLING_ENGINE which can store the name?

mehdisadeghi commented 8 years ago

Or did you mean that there should be CUBA.MODELLING_ENGINE which can store the name

Yes, exactly. We need CUBA keys to represent engines, visualizers and their corresponding parameters in order to have an independent and inter-operable CUDS. The goal is to abstract away wrappers from users. They would be instantiated by SimPhoNy based on the metadata information present inside the CUDS.

mehdisadeghi commented 8 years ago

@kemattil However, this needs to be discussed more. In order to instantiate a wrapper SimPhoNy would need to know the wrappers name, i.e. the user provided name should match exactly one wrapper's name.

kemattil commented 8 years ago

Exactly.

So the user should be able to query the names of all available wrappers (+ short description) in order to assign, e.g., the CUBA.MODELLING_ENGINE variable with a correct string.

But in general the idea is ok.

mehdisadeghi commented 8 years ago

In any case, wrappers should register themselves to SimPhoNy in a consistent way. Each wrapper which is available at simphony.engine entry point, should either implement something like a variable filled with its wrappers or a method like get_wrappers which does the same thing when called. This way, we can make sure that SimPhoNy knows how to find the corresponding wrappers.

ahashibon commented 8 years ago

Knowing and documenting the exact engine used to produce data from one simulation is an important point. The engines name and the version of the engine (release data etc), should be part of the metadata. One can then either define a simple key for the engine, e.g.: CUBA.LAMMPS_$VERSIONSTRING or define a CUBA.ENGINE as a child of CUDS component (i.e., it will have uuid, name, description, and additional attributes as CUBA.VERSION).

mehdisadeghi commented 8 years ago

I just made a PR which adds new keywords for different software tools, please review and comment.

https://github.com/simphony/simphony-metadata/pull/14

mehdisadeghi commented 8 years ago

@ahashibon @ahashibon @kemattil

Please review the latest changes to the https://github.com/simphony/simphony-metadata/pull/14.

ahashibon commented 8 years ago

apart from some comments, all seems good to me.

mehdisadeghi commented 8 years ago

Done as part of #14.