Skip to content

Extension of XML project files

Karsten Rink requested to merge github/fork/rinkk/XmlProjectProcessExtension into master

This is an extension of the OGS project file based on a discussion with @endJunction and @TomFischer . Project files will store geometry and mesh info as before, but conditions as well as materials and numeric files will be stored process-dependent.

An example file look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" href="OpenGeoSysProject.xsl"?>

<!DOCTYPE OGS-PROJECT-DOM>
<OpenGeoSysProject xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.opengeosys.org/images/xsd/OpenGeoSysProject.xsd" xmlns:ogs="http://www.opengeosys.org">
 <geofile>WESS Rivers.gml</geofile>
 <geofile>WESS Boundary.gml</geofile>
 <mshfile>Ammer-Homogen100m-Final.vtu</mshfile>
 <process type="Undefined">
  <cndfile>process-name.cnd</cndfile>
 </process>
</OpenGeoSysProject>

A few remarks:

  • new project files based on this PR are not compatible with old ones (and the vice versa, the reader will no longer read the old project files (I do not think this is actually an issue, but it's worth mentioning)
  • when more than one process exists (i.e. in case of process coupling) multiple cnd-, mat- and num-files will be written (one for each process). this is at least for the cnd-files not an actual requirement but based on this project structure it is ... this is worth discussing, I don't know if this is desired behaviour.
  • I noticed that BoostVtuInterface is not actually derived from XMLInterface although it should be. This might just be an oversight but should be fixed nonetheless.
  • writing and reading of mat- and num-files is currently just dummy-code as the interfaces do not yet exist
  • somehow the interface needs to be able to extract existing processes from ProjectData. this is currently not implemented but needed for the structure of the file
  • I define the process type as an enum in the schema file, i.e. this is duplicate information. This needs discussion if it is desired or not. (pro: process-type can be checked during validation, con: the information needs to be maintained twice (in FEMEnums and in the Schema-file))
  • no file type needs to be present according to the schema (minOccurs=0). this is not desired during simulation but imo necessary for model-building (i.e. DataExplorer) when not all information is already existing but project files might already be used. needs discussion.
  • we should discuss stn-files. imo the extended information in comparision to pure geometry is useful but I am not sure if an extra file-type is needed and how to manage them in the code / in case studies.

Merge request reports