[MBDyn-users] Refactoring of MBDyn's NetCDF interface

masarati at aero.polimi.it masarati at aero.polimi.it
Tue May 17 10:45:41 CEST 2011


> Hi Pierangelo,
> dear MBDyn users,
>
> I'd like to rework / enhance MBDyn's NetCDF output and wanted to make
> suggestions for modifications / improvements of the current
> implementation.
> And I'd like to encourage other users who are interested in the binary
> output to bring in their ideas, too.
> The list below are some points which I felt to be important - if I
> overlooked or forgot something important please add.
>
> List of suggested modifications
> ======================
> 1.) adding a parameter / switch for toggling between a MONOTLITHIC or
> SPLITTED DATABASE
> this way the user can decide if he wants to have one (big) single  .nc
> file with the output of all nodes, joints, beams, foces, etc. in it
> (as it this is currently the case) or if he prefers to have several files
> with output sorted by element-type just exactly as it is right now the
> for text output: so to each text file would exist a corresponding binary
> .nc file existing, e.g. additional to  'output.mov'  we would have
> a 'output.mov.nc'.
> Having one single file is very handy and for small models, short time
> series or less output this might be preferrable but for large models
> with a lot of nodes/elems and long time series the file can fastly become
> impractically large even for binary format.

I think one of the key points of moving to binary was the possibility to
store all data in a *single* database, thus solving consistency of data
location.  This would be magnified by the possibility to store an echo of
the model and the simulation data in the same db.  Right now, the only way
to efficiently handle multiple executions consists in placing results in
separate folders.  My understanding of using a database for output is that
it could handle this more efficiently that a filesystem (unchecked,
though).  Unless there is a proven significant penalty I'd stick with a
monolithic file.

> 2.) adding a switch to toggle the output data type between DOUBLE / FLOAT
> to enable the user to adapt the output to his needs depending on whether
> precision or less required disk space has higher priority.

Fine.

> [ 3.) ?OPTIONAL?: thinking about a general philosophy for storing time
> independent data with informal / descriptive character to avoid problems
> in Blender ]
> The problems in Blender are caused by the NetCDF-IO routines of the SciPy
> package (which are included in the MBDyn NetCDF interface for Blender) -
> so there is no
> error in MBDyn's nc output.

I need to investigate this, it's not entirely clear to me, yet.

> But on the other hand one could discuss if it does make more sense to
> separate model topology informations from the time series data.
> I think it would increase the overview having a small file with the model
> specific information (total number of nodes & elements and their mbdyn
> types, references between nodes & elems, etc.)
> Model topology information could be written into a binary nc file, too,
> but I think these might be better written in XML(?) for displaying the
> relations between items in a tree view.
> Maybe someone else has a better idea how the model topology could be
> visualized best ?

See above.  I'd stick with a single database.  Duplicating information
storage media and format can only lead to further misalignment,
duplication of efforts and so.  If you need to further obfuscate
information by rendering it in XML, you can write a simple NetCDF to XML
converter, if it does not exist yet.  The connectivity structure of a
model is simple enough that it can be simply written using
cross-references between entities, and reconstructed using simple logics
whatever the tool and the format.

> 4.) completion of the list of elements with NetCDF-output capabilities

Fine.

Cheers, p.



More information about the MBDyn-users mailing list