WorkFlows - 2019 - spring

General discussion about Elmer
joni
Posts: 21
Joined: 10 Mar 2018, 15:05
Antispam: Yes

WorkFlows - 2019 - spring

Post by joni » 04 Mar 2019, 13:26

hi,

I had several year's break for useing ElmerFEM.

Elmer it self is at good condition but applications
before are at moment suffering "depency locks",
unsupported compatibelity,....

Salomè works fine, you can mesh whit netgen
and export as .unv You can name boundaries at
salome by setting group at mesh before export.
Salomè has add-one plugin that dose not support
current version, actually problem is at calling conevtions
of functions and I have "corrected" version for testing
- if there is time.

FreeCAD, has limitations at meshing. Only GMESH
works whit Elmerfem trough FEM WorkBench. You find at ElmerFEM workflows
python script helping batch prosessing.
You can export mesh as .unv but I did not find a way to
declare boundaries, give name for boundaries so I can
referense those at case.sif for elmer.

Whit 6.2 Netgen I get crash, floating point exeception,
it come's while writeing outstream.n < P.Z() so native
export won't work. Basically current netgen accept's
all format's in but could not find feasible way to get
those out. Could this be related used parameter
types int32/int64/int128 ??? At older versions
you could define those, at now I could not find
system in minutes,...
This is pitty due Netgen dose good work and
timely manner whit large net's,... I got 6.2 Netgen
work whit FreeCAD,... just turn off OCC and python.
To get Netgen accept your own compilation of OCE
you should have empty build directory and pass
OCE directories correctly,... all other flags as well,
there must be mistake at Netgen cmake files,...

Salomè is immune to depencyes but Elmer / FreeCAD
/Negen are NOT!
========================================
OCC / OCE causes conflict between FreeCAD / Netgen
Python3 work's both FreeCAD 0.18 (2 or 3) and Netgen 6.2 (must be 3)

Incorrect OCC libraryes causes error messages hard to trace
time to time.

I like to get commnets if you know better, I lost several day's
to learn all these,...

It's not enough just to cmake cmake-gui ldd and compare,....
...

Also there is lot of libraryes that are depend eighter OCC or python.

So wheter I need a all applications build from sources at one directory
shared at my cluster or do I use native ubuntu 18.04 packaging ???

I'am about create mpi4you package,... it's also time consuming,...

NJank
Posts: 98
Joined: 05 Dec 2009, 00:05
Location: Baltimore, MD, USA

Re: WorkFlows - 2019 - spring

Post by NJank » 05 Mar 2019, 00:42

you are working from a different platform than me (I'm on Windows), but I think I somewhat understand your frustration. Since I have the benefit of 99% of my simulation work being 2D, this is exactly the reason that I prefer for a single simulation tool:

staying within ElmerGrid for meshing --> Elmersolver with SaveData --> ElmerPost / GNU Octave for post processing. output to vtk when quality visuals needed.

for parameter sweeps / optimization, using Octave as controlling program to call Elmergrid & Solver, manually building text files for inputs and parsing them for output, using MATC to move parameters from Octave to both ElmerGrid and Solver, worked very well. The simple, intuitive geometry definition, support for automatic mesh refinement and other complex features worked great. if only the old mesh2d support still worked full automatic meshing would work in elmer with no outside tools.

This workflow worked very well up until ~2013 when I was using Elmer heavily. Keeping all function within a single toolset was ideal. At one point I tried reproduce an simple elmergrid mesh with gmsh, the input file was 10x longer, making parameterized control harder.

I was never able to produce a useful workflow incorporating elmergui.

Starting up with the program again after 5 years, It seems there was an intentional or unintentional decision to deprecated elmerpost and maybe elmer grid, and just to have elmer focus on solver and gui. Don't know if that's actually the case, but your experience seems to echo a good reason to keep solid, basic functionality working within Elmer.

joni
Posts: 21
Joined: 10 Mar 2018, 15:05
Antispam: Yes

Re: WorkFlows - 2019 - spring

Post by joni » 05 Mar 2019, 11:27

hi, you said Octave,... try SAGEMATH, it's python and you can still run old octave code
under it! i have own sagemath server running. Elmer could take benefit as
part Jupiter development at future ? As future enviroment Jupiter sounds good
even I'am running own old fashion sagemath server,...

Old workflow was:

Salomè -> Netgen ( separate, standalone) -> ElmerFem -> Paraview ( separate, STANDALONE)


Now work's:

Salome+libnglib.lin ->.unv-> ElmerFem -> ParaViev

FreeCAD -> .brep ->Salomè ( Freecad meshing has too many limitations and elmerfem integration dose not eor easykly yet)

It will be problem whit BOUNDARYE nameing and matching,..


About running MPI past problem was that mpich can not shutdown "MAD" process,..
I'am starting to use slurm now,.... let see if it works better.

joni
Posts: 21
Joined: 10 Mar 2018, 15:05
Antispam: Yes

Re: WorkFlows - 2019 - spring

Post by joni » 06 Mar 2019, 15:21

More to note,... elmerfem ResultSolver generated .vtu is not
supported anymore if understood correctly,.. you only line from plate!!!

===========Paraview say's
Generic Warning: In /build/paraview-lH8wFv/paraview-5.4.1+dfsg3/VTK/Rendering/VolumeOpenGL/vtkOpenGLVolumeTextureMapper3D.cxx, line 57
vtkOpenGLVolumeTextureMapper3D::vtkOpenGLVolumeTextureMapper3D was deprecated for VTK 7.0 and will be removed in a future version.
===========

So next I have to test if Mikko Lyly's hdf5 writer, if still work's and get's
output to paraview?

it have to be compiled and installed manually from Elmer Soures / misc
/mpi/S5/elmerfem/misc/xdmf

As I understand there is not other solution to get results to PARAVIEV ???

raback
Site Admin
Posts: 3704
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: WorkFlows - 2019 - spring

Post by raback » 06 Mar 2019, 18:15

Hi joni

What is your problem with paraview & vtu output format?

-Peter

joni
Posts: 21
Joined: 10 Mar 2018, 15:05
Antispam: Yes

Re: WorkFlows - 2019 - spring

Post by joni » 06 Mar 2019, 19:56

One problem was that ResultOutput section was missing,
but even having it it says:

==
Generic Warning: In /build/paraview-lH8wFv/paraview-5.4.1+dfsg3/VTK/Rendering/Volume/vtkVolumeTextureMapper3D.cxx, line 680
vtkVolumeTextureMapper3D::vtkVolumeTextureMapper3D was deprecated for VTK 7.0 and will be removed in a future version.

Generic Warning: In /build/paraview-lH8wFv/paraview-5.4.1+dfsg3/VTK/Rendering/VolumeOpenGL/vtkOpenGLVolumeTextureMapper3D.cxx, line 57
vtkOpenGLVolumeTextureMapper3D::vtkOpenGLVolumeTextureMapper3D was deprecated for VTK 7.0 and will be removed in a future version.
==


But i found old *.sif this so I get
more controll,...

Solver 1
Equation = Result Output
Output File Name = ResUlt
Save Geometry Ids = True
Output Format = Vtu
Binary Output = False
Procedure = "ResultOutputSolve" "ResultOutputSolver"
Exec Solver = After Simulation
Scalar Field 4 = Vonmises
Scalar Field 2 = Stress_yy
Scalar Field 3 = Stress_zz
Scalar Field 1 = Stress_xx
End

So I get finaly
1) defined stress to face
2) boundary to line
3) force to node

!!!
Thanks,...

raback
Site Admin
Posts: 3704
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: WorkFlows - 2019 - spring

Post by raback » 06 Mar 2019, 23:08

Hi

These seem to be paraview complaints.

You can create a default save setup for vtu output simply saying in Simulation section

Code: Select all

  Post File = case.vtu
Instead of suffix .ep.

-Peter

NJank
Posts: 98
Joined: 05 Dec 2009, 00:05
Location: Baltimore, MD, USA

Re: WorkFlows - 2019 - spring

Post by NJank » 07 Mar 2019, 00:48

raback wrote:
06 Mar 2019, 23:08
You can create a default save setup for vtu output simply saying in Simulation section

Code: Select all

  Post File = case.vtu
Instead of suffix .ep.
I haven't been able to test how that works with transient adaptive mesh refinement relative to what we worked on a few years ago with ResultOutputSolve. does it still capture the full progressive mesh?

NJank
Posts: 98
Joined: 05 Dec 2009, 00:05
Location: Baltimore, MD, USA

Re: WorkFlows - 2019 - spring

Post by NJank » 07 Mar 2019, 01:29

testing a transient model that used to use ResultOutputSolve, post file = file.vtu only seems to save one file in the mesh folder, not the transient result. do any of the resultoutputsolver keywords work in the simulation block for post file?

raback
Site Admin
Posts: 3704
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: WorkFlows - 2019 - spring

Post by raback » 07 Mar 2019, 11:02

Hi NJank,

Actually all keywords of ResultOutputSolve work in the simulation section if you have "Post File = *.vtu". You just have to give them namespace "vtu:" before the keyword. Note also that the type of the variable as it is not known a priori for the parser and therefore the type has to be given (Logical, Integer,..).

This just creates an instance of ResultOutputSolver automatically. Hence if you have some problems they won't be resolved. I could have a look if the vtu file is not working in adaptive cases. Just create a minimal setup and I'll try to figure out the problem.

-Peter

Post Reply