Feature/povolny1/multibody vtk #1742
Conversation
…gianFEM to interface with multibody problems...WIP
…p<string,array1d<string>> SolverBase::m_meshTargets to hold target MeshBodies and regions instad of just regions.
…csLagrangeFEM. Intent is to replace m_solidMaterialNames in physics solvers...and replace all such fields in all solvers. This is not done in this commit.
…lidMechanicsLagrangiamFEM done...all other physics solvers do not compile yet!!
…ger is changed to support multi-bodies in develop
…ultipleMeshBodies
…ultipleMeshBodies
…X/GEOSX into feature/settgast/multipleMeshBodies
| void VTKVTMWriter::addDataToSubSubBlock( string const & blockName, string const & subBlockName, string const & subSubBlockName, string const & filePath, int mpiRank ) const | ||
| { | ||
| auto subBlockNode = m_vtmFile.child( "VTKFile" ).child( "vtkMultiBlockDataSet" ).find_child_by_attribute( "Block", "name", blockName.c_str() ).find_child_by_attribute( "Block", "name", subBlockName.c_str() ); | ||
| auto subSubBlockNode = subBlockNode.find_child_by_attribute( "Block", "name", (blockName + "_" + subSubBlockName).c_str() ); |
There was a problem hiding this comment.
It was pointed out in PR #1717 that this code should be refactored such that the naming convention blockName + "_" + subSubBlockName is established in a single scope, rather than split across two functions. Suggestions were to either group addSubSubBlock and addDataToSubSubBlock in a single function, or create a new additional function that is called by addSubSubBlock and addDataToSubSubBlock which returns blockName + "_" + subSubBlockName. Right now I'm leaning towards the latter since addSubSubBlock and addDataToSubSubBlock are called different amounts of times.
| * @param[in] subSubBlockName Name of the subSubBlock (usually the name of the Region) | ||
| * @param[out] the sub-sub-block name consistent with the chosen naming convention | ||
| */ | ||
| string subSubBlockNamingConvention(string const & blockName, string const & subSubBlockName) const; |
There was a problem hiding this comment.
This function can surely be static and private.
Do not use @param[out] here: the proper doxygen tag is @return.
Maybe rename into buildSubSubBLockName which is clearer? The fact that it abides by a naming convention is documented in your @brief.
| @@ -711,6 +711,7 @@ void VTKPolyDataWriterInterface::writeSurfaceElementRegions( real64 const time, | |||
| * @param[in] vtmWriter a writer specialized for the VTM file format | |||
| */ | |||
| void writeVtmFile( real64 const time, | |||
| string const meshBodyName, | |||
There was a problem hiding this comment.
We usually provide string and constant references.
Adding in support for VTK output when using multiple mesh bodies.