Closed rfaasse closed 3 months ago
I had a look in the second point that was mentioned in the description (moved it to this comment now, see below). The reason no outputs were seen was because in the ProjectParameters.json of the reproducer, the start and end time were both 1.0. When running this through the c++ DGeoFlow route, start and end time are hard-coded, so DGeoFlow will still produce results.
When we tried to run the calculation ourselves, the result file did not deliver the expected outcome, as you can see in the picture above (left hand). The file only reports the coordinates of gauss points (so only the header is printed), as shown in the screenshot below:
We've identified an issue with the results obtained from DGeoFlow when the calculation runs specifically in the time step specified as '1.0' both for "start_time" and "end_time":
Currently, instead of the expected constant time step of 0 in the results, we are observing two time steps (0 and 1). Regardless of the incorrect time steps, the results are identical. This is a screenshot of the results, where the left one is done with the latest changes and the right one is the release version (https://dpcbuild.deltares.nl/buildConfiguration/GEOFEA_KratosGeo_Compile?branch=&buildTypeTab=overview&mode=builds&tag=DGeoFlow-2023.2):
You can find the files of this calculation in: "N:\Deltabox\Bulletin\fathian" -> 'DGeoFlow.zip' Another reproducer with the old and new results are found in GeoFlowBug.zip
Acceptance Criteria Given the user runs DGeoFlow When the user checks the results Then all results are written at the expected time step (in DGeoFlow this is a hardcoded 1)
The only variable for which this doesn't hold yet, is the HYDRAULIC_HEAD.