Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Pages: 1
Hi,
I'm trying to read back a result file exported from Aster v11.3.0-2 in MED format, but the timesteps are scrambled.
It worked for some times before, but now it doesn't. I'm not quite sure if it's a problem with the exporter or Gmsh.
Basically I checked the result file with ViTables (tool to read HDF5 files) and I see the displacement results.
They are named '000000000XXX000000000XXX' where XXX is the time step (NUME_ORDRE), and there is an associated property PDT (I guess 'Pas De Temps') which has the correct timestep value (INST). However these fields appear in any order in the result file. My guess is that Gmsh simply read back the fields in the order of the file without interpreting any of the associated properties or field name. I end up with a Gmsh post-processing view with correct results, but the timesteps are not ordered.
I can't post a demo here, I use a custom Aster version with a custom behavior law. Sorry :'(
I tried specifying a list of NUME_ORDRE to IMPR_RESU to force the writing order in the file but it didn't work.
I tried upgrading Gmsh from 2.6.0 to 2.8.2 but nothing changed. This is rather annoying. I know it appears like a Gmsh bug, but since IMPR_RESU in Gmsh native format is not upgraded to v2 "because Gmsh reads MED" (official reason I was given), if the MED export is also unusable, then there is no way to use Gmsh with Code_Aster. Or is there?
Has anybody experienced this before? I couldn't find any information about this "bug".
Thanks.
PS: I have negative timesteps (INST = -1.0) for static preload before the dynamic simulation, maybe it doesn't help (I saw a field '-000000001-000000001' in the MED file).
EDIT: I opened a ticket on Gmsh trac (https://geuz.org/trac/gmsh/ticket/218)
Last edited by humbert (2013-12-02 02:08:51)
Offline
hello
which Gmsh version are you using?
i noticed this kind of behavior in one version a few month ago,
i reported it and it was quickly corrected
jean pierre aubry
consider reading my book
freely available here https://framabook.org/beginning-with-code_aster/
Offline
Hi,
Thanks for the reply. I tried with Gmsh:
- 2.6.0.dfsg-2 (Ubuntu quantal amd64)
- 2.8.2+dfsg-1 (Ubuntu saucy amd64)
- 2.8.3+dfsg-4 (Ubuntu trusty amd64)
And Christophe Geuzaine just accepted my bug report ticket (see links in my original post; login/password is gmsh/gmsh).
Could you try the attached file with your Gmsh please? Just to see if mine is broken or it's more general...
[ EDIT: I couldn't upload the file here (19Mo). It's uploaded on the Gmsh Trac : https://geuz.org/trac/gmsh/attachment/t … l-calc.med ]
Thanks
- Jerome
Offline
hello
with 2.8.4
i can read and play the file in what seems to me an orderly fashion
blocks moving along -y from step 50O to 1000, nothing important seems to happen before
as i do know what should be the results it looks ok to me
Post-pro module of Salome display a similar animation from 0 to 20
an order of magnitude slower, as expected
can you provide the med and comm to replay the whole thing
jean pierre aubry
consider reading my book
freely available here https://framabook.org/beginning-with-code_aster/
Offline
Hi,
There's a bug in one version of MED. I don't remember precisely which one (3.0.4 maybe) but since all your tests were done with the ubuntu packaged version of Gmsh, this is likely the source of the problem.
You should check by downloading the binary version provided on the Gmsh web site.
TdS
Offline
Hi,
Thanks for the replies. There is indeed a bug in the packaged version of MED (and not Gmsh). I upgraded libmedc1 from 3.0.3-3 to 3.0.6-2 (amd64) and everything works well now. Gmsh was never a problem in the first place.
Closing as solved... even though leaving this kind of bug in a packaged version is awful.
Offline
Pages: 1