[MBDyn-users] Output time period in *.log -> work around using an abstract node
masarati at aero.polimi.it
Thu Feb 17 10:10:05 CET 2011
Rix, Patrick wrote:
> Hello Jens, (hi Pierangelo)
> I'm not sure if this helps, but in the meantime until Pierangelo has
> added an additional column with a "written time step marker"-flag to
> the *.out file (..I missed that, too) you can try to capture the
> simulation time in an abstract node whose output would contain only
> the time values of those steps triggered by the outputmeter.It's a
> little bit clumsy that way, but that's how we solved this problem.
I think it's a pretty clever solution; the only drawback I see is that
it's wasting one equation, although decoupled from the others and thus
efficiently handled by sparse solvers without affecting the quality of
> Well at least it's working and it should even work when using
> variable time step strategy for the simulation. I attached a zip file
> with an example. The desired time output should appear in the *.abs
> file in the 2nd column of abstract node 11.
> Reducing the output right at run time and afterwards via
> post-processing was something I worked on for a while some time ago
> (to get rid of dealing with huge text files). I also investigated
> into MBdynText-to-NetCDF conversion and wrote some tools giving quite
> good results: reduction in file size by factor ~4 for
> MBDynText-to-NetCDFfloat conversion (converting from floats to
> 2byte-ints finally would result in approx. 8 times less compared to
> text format); if you are interested I can send you a test-version.
> @Pierangelo: I'd like to add another wish to the list apart from
> having a "written time step marker"-flag: --> would it be possible
> (with acceptable effort) to add a switch to control the number format
> for binary NetCDF-output, allowing to choose between DOUBLE and
> FLOAT ?
It's not "impossible", but it would require casting data from double to
float before calling NetCDF functions, while right now we simply pass
the double arrays that contain each datum. Not a huge overhead in
addition to coding. I'll consider it, thanks.
More information about the MBDyn-users