Page 1 of 1

issues with VTU output generation, adaptive/tranisent solutions

Posted: 08 Mar 2019, 20:17
by NJank
wanted to collect these issues in this forum that were discussed over in this General thread:
http://elmerfem.org/forum/viewtopic.php?t=6599

working to update the Adaptive Mesh example over in Contributed Cases, I ran into issue with specifying VTU output from the Simulation block.

attached are adapt.grd and adapt.sif files set up for transient versions of that Contributed Case. the heat equation is solved for a block with a cold base and heated top region, starting at an elevated temperature. mesh refinement happens some initially, and then more as the gradient at the top develops.

vtu output is specified both as Solver 2 and in the Simulation block. the simulation block portion is commented out.

Run as is with the Solver 2 block below , one set of vtu files are created in "vtufolder" simply named "vtufile####.vtu". The "Vtu Time Collection = logical true" line also creates a "vtufile.pvd" file.

Code: Select all

Solver 2
  Exec Solver = String "after timestep"
  Equation = String "ResultOutput"
  Procedure = File "ResultOutputSolve" "ResultOutputSolver"
  Output File Name = file "vtufile"
  Vtu Format = Logical True
  Ascii Output = Logical True
  Scalar Field 1 = String "Temperature"
  Mesh Name = file "refinedmesh"
  Output Directory = file "vtuoutput"
  Vtu Time Collection = logical true
End
commenting out Solver 2 and uncommenting the lines below in the Simulation block , two sets of files are created in the vtufolder. it's unclear how keywords play into this:

Code: Select all

  Post File = file "vtufile.vtu"
  vtu: Scalar Field 1 = String "Temperature" 
  vtu: Output Directory = file "vtufolder" 
(note that a "Vtu: output file name = file "vtufile" " line seems to have no effect)

what is produced is one set of files named "adapt_vtufile####.vtu" and another set named "RefinedMesh#_vtufile####.vtu". see below

Code: Select all

3/08/2019  12:07 PM             2,519 adapt_vtufile0001.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0002.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0003.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0004.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0005.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0006.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0007.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0008.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0009.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0010.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0011.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0012.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0013.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0014.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0015.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0016.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0017.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0018.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0019.vtu
03/08/2019  12:07 PM             2,519 adapt_vtufile0020.vtu
03/08/2019  12:07 PM           181,007 RefinedMesh0_vtufile0010.vtu
03/08/2019  12:07 PM           124,399 RefinedMesh1_vtufile0002.vtu
03/08/2019  12:07 PM           140,151 RefinedMesh2_vtufile0007.vtu
03/08/2019  12:07 PM           126,511 RefinedMesh3_vtufile0003.vtu
03/08/2019  12:07 PM           126,687 RefinedMesh4_vtufile0004.vtu
03/08/2019  12:07 PM           186,936 RefinedMesh4_vtufile0011.vtu
03/08/2019  12:07 PM            93,395 RefinedMesh5_vtufile0001.vtu
03/08/2019  12:07 PM           188,472 RefinedMesh5_vtufile0012.vtu
03/08/2019  12:07 PM           127,511 RefinedMesh6_vtufile0005.vtu
03/08/2019  12:07 PM           156,871 RefinedMesh6_vtufile0008.vtu
03/08/2019  12:07 PM           189,000 RefinedMesh6_vtufile0013.vtu
03/08/2019  12:07 PM           189,352 RefinedMesh7_vtufile0014.vtu
03/08/2019  12:07 PM           172,311 RefinedMesh8_vtufile0009.vtu
03/08/2019  12:07 PM           131,375 RefinedMesh9_vtufile0006.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0015.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0016.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0017.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0018.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0019.vtu
03/08/2019  12:07 PM           189,792 RefinedMesh9_vtufile0020.vtu
The 'adapt' set seems to be the nodal solution mapped to the original unrefined mesh. The "RefinedMesh#" files include the mesh used to calculate that timestep, and matches the contents of the "vtufile####.vtu" files produced when called as a Solver block. However, the RefinedMesh#_ naming scheme breaks Paraview's ability to read in the transient group, and the reuse of refinedmesh folders puts the timesteps significantly out of order.

Finally, uncommenting the "vtu: Vtu Time Collection = logical true" line from the Simulation Block produces the following error after a few simulation iterations:

Code: Select all

ResultOutputSolver: Saving in unstructured VTK XML (.vtu) format
At line 2216 of file c:/ElmerBuild/src/elmer/elmerfem/fem/src/modules/ResultOutputSolve/VtuOutputSolver.F90 (unit = 58, file = '┴')
Fortran runtime error: File 'vtufolder/RefinedMesh1_vtufile.pvd' does not exist
at the point of the error the vtufolder contains:

Code: Select all

03/08/2019  12:16 PM               288 adapt_vtufile.pvd
03/08/2019  12:16 PM             2,519 adapt_vtufile0001.vtu
03/08/2019  12:16 PM           124,399 RefinedMesh1_vtufile0002.vtu
03/08/2019  12:16 PM               312 RefinedMesh5_vtufile.pvd
03/08/2019  12:16 PM            93,395 RefinedMesh5_vtufile0001.vtu

EDIT: this may or may not be related, but I just noticed that attempting to open the pvd file that is successfully generated by the Solver block cannot be opened by Paraview. It seems to have a filepath incorrectly specified with a duplicate /vtuoutput/vtuoutput/:

Code: Select all

ERROR: In C:\bbd\ecd3383f\build\superbuild\paraview\src\VTK\IO\XML\vtkXMLReader.cxx, line 270
vtkXMLUnstructuredGridReader (0000024B3E9781F0): Error opening file G:/Research/elmer/vtuoutput/vtuoutput/vtufile0001.vtu

ERROR: In C:\bbd\ecd3383f\build\superbuild\paraview\src\VTK\Common\ExecutionModel\vtkExecutive.cxx, line 782
vtkCompositeDataPipeline (0000024B3E043780): Algorithm vtkXMLUnstructuredGridReader(0000024B3E9781F0) returned failure for request: vtkInformation (0000024B3E1E3590)
  Debug: Off
  Modified Time: 2577474
  Reference Count: 1
  Registered Events: (none)
  Request: REQUEST_INFORMATION
  FORWARD_DIRECTION: 0
  ALGORITHM_AFTER_FORWARD: 1

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 11 Mar 2019, 11:45
by raback
Hi

Yes, there were problems. Currently the meshes are saved and the VTU output always wanted to save the 1st and the last mesh. The 1st one is actually associated to the VtuOutputSolver itself.

I added a feature that let's you choose which Solver is used to define the mesh to be saved. Other meshes will be disregarded. In this cased adding

Code: Select all

  vtu: Save Solver Mesh Index = Integer 1
will do the trick (see the attachment).

The poor naming where the Mesh Name is added is a result there being more than one mesh. When we choose one mesh as above the annoying naming also vanishes.

Maybe not a perfect fix but at least gets you going.

Thanx for reporting!

-Peter

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 11 Mar 2019, 17:46
by NJank
thanks for the quick response. any thoughts about the erroneous folder location in the pvd file?

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 12 Mar 2019, 11:44
by raback
Hi Njank,

I didn't study that. Using these settings, does the .pvd file still go to wrong location?

-Peter

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 12 Mar 2019, 17:17
by NJank
i'm running in windows and can't necessarily download/recompile any recent changes you made, but I don't think the keyword you mentioned would affect the pvd file, would it? setting for pvd creation in the Simulation block still throws the Fortran runtime error:

Code: Select all

At line 2216 of file c:/ElmerBuild/src/elmer/elmerfem/fem/src/modules/ResultOutputSolve/VtuOutputSolver.F90 (unit = 58, file = 'F')
Fortran runtime error: File 'vtufolder/RefinedMesh1_test.pvd' does not exist


and putting it in the solver block creates a pvd file with an incorrect folder name (the vtu folder name is entered in the path twice).

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 12 Mar 2019, 18:08
by mzenker
NJank wrote: 12 Mar 2019, 17:17 i'm running in windows and can't necessarily download/recompile any recent changes you made [...]
Indeed, the latest nightly build on http://www.nic.funet.fi/pub/sci/physics ... in/windows is two months old.
@Elmer team: Are those nightly builds not built nightly any more...?

Matthias

Re: issues with VTU output generation, adaptive/tranisent solutions

Posted: 14 Mar 2019, 01:36
by raback
Hi

Virtual machine disk space had filled up. At least the .exe files should now be updated automatically. Have to still look why the .zip files didn't appear.

-Peter