Anyone out there using UCDIO?
We have a collaborator (not using libMesh) that needs to read in mesh and
solution results from one of our libMesh applications using the UCD format
(well, this is easiest route anyway). Currently, only the nodes and
elements of the mesh are written out. I'm going to add two more categories:
boundary id information and solution variables.
The solution variable output is well defined by the UCD format, but there's
no formal inclusion for boundary info. What's been done by the CUBIT and
deal.ii folks is to write out the boundary element data as additional
elements and make the material id for the boundary element correspond to
the boundary id (note there are no duplicate nodes AFAICT). I'm going to
follow this route. The only hiccup is that UCD doesn't understand 1D
elements, so the boundary output is only well-defined for 3D meshes.
My plan is to add a flag to the UCDIO constructor to enable boundary
element output that defaults to false (not writing out boundary data) and
kicks back an error for 2D meshes if true. This shouldn't break backward
compatibility since 1. by default, boundary element data won't be written
out and 2. we'll be adding the write_nodal_data method to UCDIO thereby
enabling write_equation_systems so solution variables will only be written
out then while only the mesh data will be written out with UCDIO::write. At
any rate, I wanted to give a chance for anyone to scream before getting too
far down the road.
Best,
Paul
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
