ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-03-19T10:00:24+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/270Plotting: Obtain number of elements hold by an MPI rank before plotting grid ...2019-03-19T10:00:24+01:00Francesco FambriPlotting: Obtain number of elements hold by an MPI rank before plotting grid sweepI was looking for any strategy able to give me, for every MPI rank, the total number of cells (if possible, distinguishing between limited and non-limited cells).
A possibility was to use the plotpatches of ADERDG, counting unlimited cel...I was looking for any strategy able to give me, for every MPI rank, the total number of cells (if possible, distinguishing between limited and non-limited cells).
A possibility was to use the plotpatches of ADERDG, counting unlimited cells, and of FV, counting limited cells, but the problem is that...
I need this info for the startPlotting of the userdefined Writer, because for my plotter I need to allocate a very big array that, a-priori, should be able to contain all the info that has to be plotted for a given MPI rank.
besthttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/269Carpet Plotter Warnings in 2D2019-03-21T10:41:29+01:00Ghost UserCarpet Plotter Warnings in 2D> In 2D, I get the following warnings all the time. Can you take a look at it:
```
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:202:8: warning: unused variable ‘isNotInAny...> In 2D, I get the following warnings all the time. Can you take a look at it:
```
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:202:8: warning: unused variable ‘isNotInAnyGhostLayer’ [-Wunused-variable]
> bool isNotInAnyGhostLayer = tarch::la::allSmaller(icell,numberOfCellsPerAxis+ghostLayerWidth) && tarch::la::allGreater(icell,ghostLayerWidth-1);
> ^~~~~~~~~~~~~~~~~~~~
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:205:8: warning: unused variable ‘isNotInCornerGhostLayer’ [-Wunused-variable]
> bool isNotInCornerGhostLayer = !(tarch::la::allSmaller(icell, ghostLayerWidth) || tarch::la::allGreater(icell, numberOfCellsPerAxis+ghostLayerWidth));
> ^~~~~~~~~~~~~~~~~~~~~~~
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:207:8: warning: unused variable ‘justIgnoreTheCornerProblem’ [-Wunused-variable]
> bool justIgnoreTheCornerProblem = true;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.h:177:0,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/parser/Parser.h:33,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Plotter.h:21,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.h:19,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:16:
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph: In member function ‘void exahype::plotters::FiniteVolume2Carpet::interpolateCartesianSlicedVertexPatch(const tarch::la::Vector<2, double>&, const tarch::la::Vector<2, double>&, double*, double*, double, const exahype::plotters::CartesianSlicer&)’:
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/266Write plotters which really plot limited DOF where the limiter is active2019-03-21T10:41:52+01:00Ghost UserWrite plotters which really plot limited DOF where the limiter is activeFor VTK, this is straightforward.
For other formats, this is a nice to have.For VTK, this is straightforward.
For other formats, this is a nice to have.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/265Implement VTU support for Python VTK offline slicer2019-03-21T10:40:44+01:00Ghost UserImplement VTU support for Python VTK offline slicerSven, debug the old python VTK slicer, available at `Miscellenaeowtfusous/PostProcessing/`.
@lbovard please provide some exemplaric VTK/VTU files :-)Sven, debug the old python VTK slicer, available at `Miscellenaeowtfusous/PostProcessing/`.
@lbovard please provide some exemplaric VTK/VTU files :-)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/262Get CarpetASCII 1d cut working on different machines such as hazelhen2019-03-06T18:27:47+01:00Ghost UserGet CarpetASCII 1d cut working on different machines such as hazelhenLuke reported that it did not work for him.
But it does no more depend on HDF5 so we should get this working...
@lbovardLuke reported that it did not work for him.
But it does no more depend on HDF5 so we should get this working...
@lbovardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/222Fix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpph2019-04-15T12:41:12+02:00Ghost UserFix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpphFrom a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the tim...From a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the time since program start.
>
In ExaHyPE, the grid setup sometimes takes a considerable amount --
like 10 minutes. If you measure the M/h straight after the first
timesteps after these 10 minutes, you get of course totally wrong
numbers. However, if you measure after 1000 minutes runtime, the 10
minutes grid setup do not change the result so much.
>
It is not hard to substract the time the grid setup needs in order to
improve the correctness of the number. You can do this either by hand
(just look up when the first time step started) or we can do this in
code (CCZ4/Writers/TimingStatisticsWriter.cpph).https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/215User Defined plotters API: Pass the information from the specfile2019-04-15T12:36:16+02:00Ghost UserUser Defined plotters API: Pass the information from the specfileHow can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is so...How can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is something I can do :)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/213Named variables in VTK plots2018-09-10T19:38:52+02:00Ghost UserNamed variables in VTK plotsI want to have them. I will implement this tonight via the plotter mapping class as an optional virtual function (isn't this already there? HDF5 uses it) and pass the data straight forwards throught VTK. This will result in a patch for p...I want to have them. I will implement this tonight via the plotter mapping class as an optional virtual function (isn't this already there? HDF5 uses it) and pass the data straight forwards throught VTK. This will result in a patch for peano.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/212Number of Plotters is not detected2018-09-10T19:43:27+02:00Ghost UserNumber of Plotters is not detectedWhen you compile an ExaHyPE application with a Specfile with *n* plotters but run it with *m* plotters (say the types of the first *m-n* plotters are the same), there is no detection that `m != n`. This leads to weird errors which even a...When you compile an ExaHyPE application with a Specfile with *n* plotters but run it with *m* plotters (say the types of the first *m-n* plotters are the same), there is no detection that `m != n`. This leads to weird errors which even are hardly understandable in DEBUG mode:
```
0.0310583 15:50:15 [nils]rank:0 debug exahype::parser::Parser::getIdentifierForPlotter() found token notoken (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:999)
assertion in file /home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp, line 1001 failed: token.compare(_noTokenFound) != 0
parameter token: notoken
parameter solverNumber: 0
parameter plotterNumber: 3
ExaHyPE-GRMHD: /home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp:1001: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> exahype::parser::Parser::getIdentifierForPlotter(int, int) const: Assertion `false' failed.
Abgebrochen
```
but completely nonunderstandable in Release mode:
```
0.00535548 15:32:20 [nils]rank:0 error exahype::parser::Parser::getFirstSnapshotTimeForPlotter() 'GRMHDSolver_FV' - plotter 3: 'time' value must be a float. (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:1046)
0.00538875 15:32:20 [nils]rank:0 error exahype::parser::Parser::getRepeatTimeForPlotter() 'GRMHDSolver_FV' - plotter 3: 'repeat' value must be a float. (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:1067)
```
note that in this example, `n=4` and `m=3`, so especially plotter 3 looked allright where the error message tried to complain actually about the nonexisting plotter 4.
This is very bad. We need some better enforcement of this rule.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/210Efficent output format for large simulations2018-03-02T13:23:47+01:00Leonhard RannabauerEfficent output format for large simulationsAs soon as output reaches a certain size plotting is our major bottleneck. (a mesh of ~40 mio dofs with 14 unknowns for pvtu on supermuc takes 1h per plot)
We should look into different approaches like the ASYNC lib https://github.com/TU...As soon as output reaches a certain size plotting is our major bottleneck. (a mesh of ~40 mio dofs with 14 unknowns for pvtu on supermuc takes 1h per plot)
We should look into different approaches like the ASYNC lib https://github.com/TUM-I5/ASYNC which sacrifices a singe thread per rank on output.
For supermuc: We should also start to look into parallel file systems like LUSTRE https://en.wikipedia.org/wiki/Lustre_(file_system).Leonhard RannabauerLeonhard Rannabauerhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/202Segfault in some VTK plotters if variables = 02019-03-21T10:48:34+01:00Ghost UserSegfault in some VTK plotters if variables = 0https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/197Let tarch VTK plotters pass file creation errors to ExaHyPE plotters2018-03-02T12:46:18+01:00Ghost UserLet tarch VTK plotters pass file creation errors to ExaHyPE plottersThis is something where I want to patch Peano and subsequently send the patch to Tobias:
Currently it's annoying that some ExaHyPE plotters stop the program when they cannot open output files (the ASCII/CSV writers as well as my CarpetH...This is something where I want to patch Peano and subsequently send the patch to Tobias:
Currently it's annoying that some ExaHyPE plotters stop the program when they cannot open output files (the ASCII/CSV writers as well as my CarpetHDF5 writer) while other silently ignore this issue (Tobias tarch-based VTK writers). Clearly, we want the user to be able to control whether problems at output shall be severe or not.
I can easily implement this in the ExaHyPE codebase, but I don't control peano, so I have to make sure Peano passes such errors into exahype's domain.
=> TODO @ Sven.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/160Support a Tecplot-compatible output format2018-06-15T15:13:42+02:00Ghost UserSupport a Tecplot-compatible output formatThis is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common ...This is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common denominator VTK. Instead, a number of file formats are supported in-house:
```
• CGNS Loader
• DEM Loader
• DXF Loader
• EnSight Loader
• Excel Loader
• FEA Loader
• FLOW-3D Loader
• FLUENT Loader
• General Text Loader
• HDF Loader
• HDF5 Loader
• Kiva Loader
• PLOT3D Loader
• PLY Loader
• Tecplot-Format Loader
• Text Spreadsheet Loader
```
See also: http://home.ustc.edu.cn/~cbq/360_data_format_guide.pdf with meaningful pictures as this one:
![beautiful-tecplot-nodal-values](/uploads/c4ea3adb5281c5c2f713199792c50f53/beautiful-tecplot-nodal-values.png)
Instead of Trentos code, we don't want to implement a writer which writes only the tecplot-specific format but instead use some of these widespread formats, for instance "FLUENT" or so.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/152Dynamic plotter registration2019-03-07T19:39:00+01:00Ghost UserDynamic plotter registrationUsers shall be able to add, comment out or remove plotters at runtime without recompiling. The plotter ordering should not be fixed.
This is not too hard to obtain, just requires changes at `KernelCalls.cpp` with having a generated plot...Users shall be able to add, comment out or remove plotters at runtime without recompiling. The plotter ordering should not be fixed.
This is not too hard to obtain, just requires changes at `KernelCalls.cpp` with having a generated plotter registration function (semi pseudocode)
```c++
Writer* kernels::getNamedWriter(std::string name, Solver& solver) {
if(name == "ConservedWriter") return new GRMHD::ConservedWriter(*static_cast<exahype::solvers::LimitingADERDGSolver*>(solver));
if(name == "usw") return new GRMHD::SomeOtherWriter(*static_cast<exahype::solvers::ADERDGSolver*>(solver));
if(name == ...
else
failure: Dont now this plotter type.
}
```
We then can replace the generated current section
```c++
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,0,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,1,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,2,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,3,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,4,parser,new GRMHD::IntegralsWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
```
with a non-generated section (pseudocode)
```c+++
for(const int& solvernum : Parser->getSolvers()) {
int plotternum=0;
for( const string& plottername : Parser->getPlotterNamesForSolver(solvernum)) {
exahype::plotters::RegisteredPlotters.push_back(new exahype::plotters::Plotter(solvernum,plotternum++,parser,getNamedWriter(plottername, exahype::solvers::RegisteredSolvers[solvernum]));
}
}
```
This is something I can do on my own. If the Parser gives the neccessary data...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/123Derivative plotter, part 22018-06-15T15:13:43+02:00Ghost UserDerivative plotter, part 2We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is ...We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is something I can try to do.