Loading an ARMI DB when you don't have the App that created it

[john-science]

Right now, the story goes that you can't load an ARMI DB if you don't have the ARMI App that was used to create the DB in the first place.

This displeases me.

It means a lot more overhead in sharing ARMI outputs. You need to go find the App in question, get all its data and cruft, just to load an H5 file. ARMI should be easier to use than that.

So, the question is: Why do you need the App?

• You need the App because that's where the Parameters in the Database are defined.
• You need the App because it defines the Settings in the cs object.

Is there any other reason?

[john-science]

@jakehader @keckler @onufer I would love you input here. Is it just the Parameter / Settings definitions that are the issue?

This is a "I don't know what I don't know" situation.

Thanks!

[alexhjames]

I like option 3 above. Especially if the unsupported thing was also associated with the name of the plugin that created it. So for example if you loaded a database with a material that wasn't in ARMI, you would be able to see the material name at least everywhere that you would normally see the material object and also some way to see what plugin it came from. That way you would know which plugin you needed to include if you wanted to make that a fully fleshed out object on load.

For the custom classes that extend ARMI classes, like say a custom block class, it would be cool if the load could instance it as at least the closest thing in the inheritance tree that is available in ARMI and then only the missing pieces are just names that are stored. So for example, a custom block that inherits from a HexBlock would be instanced as a HexBlock and only the extended things would be listed as key/value pairs but it would still respond to other block method calls that are more general.

[keckler]

I would vote for (3).

[jeffbaylor]

I will have to think more about it, but my first impression was a hybrid of 1 and 3. The Settings and Parameter objects seem well suited to be fully defined within the database and then any missing at load time could be created.

The more complex objects like customized Block and Material objects could continue to be provided either by adding the same plugin to the loading App, or by a different plugin that defines the same interface to those objects, if the loading App wants to do anything more than view the data. If any of those objects are not defined, then the loading App enters a "Safe Mode" and provides information about what missing functionality drove it to adopt this mode. An incremental development step could be to fail if the objects are not available.

[jasonbmeng]

I like Option (3) as well. Seems like it could be fairly straightforward to implement as a starting point. More sophisticated loading functionality that has been suggested can be expanded at a later point. But in the meantime, ARMI Apps will at least be able to load and interrogate dbs generated by other ARMI Apps.

[john-science]

@jeffbaylor I believe I have a version of this that is working. Just FYI.

[keckler]

You also need for the relevant material classes to be available. If ARMI can't find a material that is used in the reactor model, you can't do db.load()

…

On Mon, Apr 15, 2024, 6:54 PM John Stilley ***@***.***> wrote: @jakehader <https://github.com/jakehader> @keckler <https://github.com/keckler> @onufer <https://github.com/onufer> I would love you input here. Is it *just* the Parameter / Settings definitions that are the issue? This is a "I don't know what I don't know" situation. Thanks! — Reply to this email directly, view it on GitHub <#1688 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFHRHMB7KHGCCCMIJIJCXCTY5RSDNAVCNFSM6AAAAABGIILXS2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMRTGY4TS> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[john-science]

Materials. Okay, damn.

Maybe we could have a "load DB in safe mode" that would load the DB with just the names of the materials, but not the full material data. You would be limited with what you could do vis-a-vis, continuing the simulation from that point point. But at least you could LOAD it.

Hmmm

[keckler]

We have an internal visualization tool (XTView) that loads DBs to some extent without having access to the original app. I'm not sure how that works, but it might be a starting point for what you're trying to accomplish here.

[ntouran]

it knows the hdf5 structure and just reads and displays data without any ARMI data model whatsoever. This means there is some duplication of geometry engines/knowledge within the two

Similarly, users can certainly open up a hdf5 file with a typical hdf5 browser and no ARMI whatsoever and read all the data out of it if you want without any changes needed to the code or DB.

[ntouran]

I feel like I'm a big fan of option 1. Storing parameter defs and settings in the DB is borderline trivial from a data magnitude perspective, and putting them in there would indeed facilitate sharing of output DBs in a way that would be more portable, e.g. into other ARMI apps or just pure framework.

Materials do scare me a little. If you're missing materials you won't really be able to e.g. get mass density and therefore won't be able to look at compositions in any detail. Then you can't getMass or anything and many of the useful ARMI post-processing features will not work.

Of course if you don't want any ARMI data model abstractions whatsoever you can just read the hdf5 file directly (this is what xtview does)