Currently, if you import a genesis file to create an smtk model, the process of saving that resource will create a uuid-named exodus file in the same directory as the resource (.smtk) file. I believe this strategy is done in order to avoid potential conflict if the native model is later modified or deleted. But this can also consume large amounts of redundant disk data if a large native model is imported into multiple resources.
To save disk space, I propose adding an option to the smtk resource system to support model resources loading the original native model file, instead of creating/using a copy.
The current logic for saving resources (creating a copy of the native model) will remain the default behavior; using the native model in-place will be an option (VoidItem) added to model import operations.
The proposed option creates a greater risk of “breaking” a resource by moving, deleting, or editing the native model; users will have to accept the risk when using this feature. To prevent changes to a native model from crashing CMB, I propose that the model resource store an md5sum of the native model file, and check it before each read operation and update it after every write operation. (Other operations involving disk I/O would also need to be modified accordingly.)
The new option could impact moving a model resource within its current filesystem (presuming the resource stores a relative path to the native model). Addressing this needs more discussion.
The new option certainly affects the ability to copy resources from one machine to another. For this, I propose we add an archive operation to bundle resource files with their native model files.
After some discussion at the CMB Core meeting today, the current thinking for implementation is:
Add an Exodus session as a subclass of the current vtk session.
Update its Write operation to use the original model file instead of writing a copy. I’m not sure if this is an option or always-on (I can live with either).
We can defer the saving and checking md5sum data if that saves time/effort.
Additional requirements were discussed at the CMB Core meeting 22-Dec-2020
The new Exodus session should use the pedigree id as the persistent identifier (instead of the order of appearance in the native model file, which the vtk session logic uses). The reason is to allow replacing the native model assigned to a resource with a variation having the same topology but different geometry (refinement and/or coarsening).
This would imply the need for a new operation to replace the native model, which wouldn’t have to be limited to matching topology. (If the replacing model topology doesn’t match, the operation would assign new UUIDs for new side set and element block ids and delete UUIDs for “missing” entities.)
We also need an easy way to set the visibility for each entity type as a group, so that our UI can make it easy to show/hide all side sets and show/hide all element blocks.
If it is of any benefit, the first implementation can ignore node sets in the native model, because they are not used for present-day ACE3P or Truchas applications.
Also, there seems to be no objection to using the SMTK graph resource for implementing the new resource and session.