You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is most likely a request for better documentation of result export and Solvers; at the least this will show up in searches.
Many xml readers error when encountering the binary formatted of the AppendedData block described here, making it difficult read result files in other programs. In tracing this 'invalid xml', I discovered the Solver options Ascii Output = True and inverse Binary Output = False, which lead to the AddVtuOutputSolverHack in ElmerSolver.F90. This was guided by setting Simulation.Max Output Level = 100 in the sif so that elmersolver.log has all info messages.
This further showed that vtu files are written by an 'InternalVtuOutputSolver' Solver which doesn't receive the Ascii Output if set by the user's Solver section.
My workaround is to manually add a second Solver copied from the InternalVtuOutputSolver at L1397 via
Solver 2
Equation = InternalVtuOutputSolver
Save Geometry IDs = True
Output File Name = case_internalVtuOutputSolver.vtu
Ascii Output = True
Binary Output = False
No Matrix = True
Variable = -global vtu_internal_dummy
Procedure = "ResultOutputSolve" "ResultOutputSolver"
Exec Solver = after saving
Output Format = vtu
End
This then produces a readable xml result file with all of the result data in the xml DataArrays:
This is True. A .vtu ending activates a ResultOutputSolver instance and keywords with namepace "vtu:" are passed alongside. So "vtu: ascii output = logical true" should work.
The original error that broke binary reading in some versions of paraview is super annoying. It worked nicely for several years and I don't know when a fix to the expat library is to be expected.
This issue is most likely a request for better documentation of result export and Solvers; at the least this will show up in searches.
Many xml readers error when encountering the binary formatted of the AppendedData block described here, making it difficult read result files in other programs. In tracing this 'invalid xml', I discovered the Solver options
Ascii Output = True
and inverseBinary Output = False
, which lead to the AddVtuOutputSolverHack in ElmerSolver.F90. This was guided by settingSimulation.Max Output Level = 100
in the sif so thatelmersolver.log
has all info messages.This further showed that vtu files are written by an 'InternalVtuOutputSolver' Solver which doesn't receive the Ascii Output if set by the user's Solver section.
My workaround is to manually add a second Solver copied from the InternalVtuOutputSolver at L1397 via
This then produces a readable xml result file with all of the result data in the xml DataArrays:
The text was updated successfully, but these errors were encountered: