BASEMENTBasic Simulation Environment for computation of environmental flow and natural hazard simulationLaboratory of Hydraulics, Hydrology and Glaciology (VAW)ETH Zurich |
You are not logged in.
Pages: 1
Topic closed
With Basement 2.4 and `.sol`-file output I noticed:
* newline missing in header leads to not reading the first time-step within SMS
currently:
DATASET
OBJTYPE "mesh2d"
RT_JULIAN 2433282.500000
BEGSCL
ND 10688
NC 20377
NAME "depth"
TIMEUNITS seTS 0 0.000000
expexted:
DATASET
OBJTYPE "mesh2d"
RT_JULIAN 2433282.500000
BEGSCL
ND 10688
NC 20377
NAME "depth"
TIMEUNITS se
TS 0 0.000000
* time-steps differ between scalar and vector data
in `run_nds_depth.sol` I have
TS 0 60.003192
whereas in `run_nds_velocity.sol` I get
TS 0 6.00032e+001
This leads to not being able to compute vector and scalar data within SMS.
Offline
michelk, thank you for your message.
The problem you encountered was a bug indeed.
We fixed it and will be included in the next bugfix release. If you need a bugfix version right now, please let us know.
cheers
Offline
Short note:
You can circumvent this problem by using the 'qgis'-type output instead of the 'sms'-type output. These file formats are identical, beside the format of the headers.
Offline
Thanks for the replies Sam and Christian.
But also with 'qgis'-type output the time-steps differ between scalar and
vector data. Right now we don't need a bugfix version, since we pipe the output
anyways though a collection of scripts. But we would appreciate a bugfix
release.
Thanks, Michel
Offline
Hi,
I just noticed, that in the header of the*_els_*.{sol,dat} files (element-centered output), node-number (ND) should be set to the number of elements of the computational mesh.
The flollowing version I use: 2.4 R1903.
Greetz, Michel
Last edited by michelk (2015-03-27 14:28:42)
Offline
Hi,
when using the Linux-2.5.2 version, sms output seems to be not correct:
Before 'TS', a newline is missing.
E.g. scalar-data
6.22650e-02
5.68073e-02 TS 0 3.000109061876e+02
0.00000e+00
0.00000e+00
or vector-data
3.25441e-01 1.26695e-01 0.00000e+00
1.73796e-01 1.19494e-02 0.00000e+00
1.51975e-01 2.37686e-02 0.00000e+00TS 0 3.000109061876e+02
0.00000e+00 0.00000e+00 0.00000e+00
0.00000e+00 0.00000e+00 0.00000e+00
with the Windows-executable this does not happen.
Greetings, Michel
Offline
Hi Michel,
Indeed, this was a bug in the linux version and will be solved in the next release.
Cheers, Lukas
Offline
Hey Michel
Please note that we just released a bugfix version (2.5.3) that solved this bug!
Best, Lukas
Offline
Pages: 1
Topic closed