Hi,
Since I am interested the fsi features of Elmer most, just compiled the latest version on linux and tested several cases.
It seems, with the "ShoeboxFsiEigen2D" case, the airdensity and soundspeed parameters have no effect on the results so is this expected with the wavesolver?
eigenFsi
Re: eigenFsi
Hello,
It almost always helps to post a minimal working example, with a sif file and geometry and the solver log output.
Rich.
It almost always helps to post a minimal working example, with a sif file and geometry and the solver log output.
Rich.
Re: eigenFsi
Hi,
I was trying this test case:
https://github.com/ElmerCSC/elmerfem/tr ... FsiEigen2D
On the other hand, after a system update, these two parameters started to effect the results as expected somehow!
I can say more if complete a 3D case vs experimental data but have another question about postprocessing. Is there a way to seperate solid and fluid parts of the results for paraview?
I was trying this test case:
https://github.com/ElmerCSC/elmerfem/tr ... FsiEigen2D
On the other hand, after a system update, these two parameters started to effect the results as expected somehow!
I can say more if complete a 3D case vs experimental data but have another question about postprocessing. Is there a way to seperate solid and fluid parts of the results for paraview?
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: eigenFsi
Hi
It seems that the WaveSolver has been written in a way where the interface matrices would need to be multiplied by density and this was not done. Alternatively the WaveSolver could be divided by density when present. This has the advantage of being correct for multiple domains. The sound speed did have an effect already before, albeit a small one.
I just committed the division of WaveSolver by density to devel branch of git. Maybe you can test whether you get the desired results.
-Peter
It seems that the WaveSolver has been written in a way where the interface matrices would need to be multiplied by density and this was not done. Alternatively the WaveSolver could be divided by density when present. This has the advantage of being correct for multiple domains. The sound speed did have an effect already before, albeit a small one.
I just committed the division of WaveSolver by density to devel branch of git. Maybe you can test whether you get the desired results.
-Peter
-
- Posts: 2237
- Joined: 25 Jan 2019, 01:28
- Antispam: Yes
Re: eigenFsi
Save Geometry Ids = Logical True
In the simulation section enables a filter in paraview to select bodies
In the simulation section enables a filter in paraview to select bodies
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: eigenFsi
Also "Vtu Part Collection = True" for ResultOutputSolver. -Peter
Re: eigenFsi
Hi,
First of all, thanks for updating the code immediately.
I re-compiled the latest devel branch and start testing.
This time the pressure affects the results, though weirdly.
Build a simple 3D fsi test case which is a 400x300x5mm stainless steel (all free) plate immersed in water because experimental and other solver results data is freely available.
Also made a solution for non-fsi case for the same plate with Elmer and of course the results were very accurate.
On the other hand with fsi case could not get a meaningful solution, just unexpected results. Normally the eigen frequencies in water must be significantly lower than in air but my results was even higher.
So turn back to Shoebox2d eigen fsi case and indeed this behaviour seems already there too.
I tried fine grids, higher order element, nothing changed.
By the way, I had difficulties with the higher order elements which behavior can be replicated with the shoebox2d eigen case (or may be this is caused by some problem with my system?)
When this case run with Mumps and "element = p:2" for both wave and NS solver there is a crash with the following message:
"EigenSolve: .. ** On entry to DLASCL parameter number 4 had an illegal value
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_OVERFLOW_FLAG"
With p:3, same. If one of them p:2 and other p:1 working and solves etc.
For 3D case this behavior is different:
both solvers with p:2 crashes with segmentation fault. It works when both p:3 etc.
As a result I was not able to get any usable result with solid in water fsi problem yet.
First of all, thanks for updating the code immediately.
I re-compiled the latest devel branch and start testing.
This time the pressure affects the results, though weirdly.
Build a simple 3D fsi test case which is a 400x300x5mm stainless steel (all free) plate immersed in water because experimental and other solver results data is freely available.
Also made a solution for non-fsi case for the same plate with Elmer and of course the results were very accurate.
On the other hand with fsi case could not get a meaningful solution, just unexpected results. Normally the eigen frequencies in water must be significantly lower than in air but my results was even higher.
So turn back to Shoebox2d eigen fsi case and indeed this behaviour seems already there too.
I tried fine grids, higher order element, nothing changed.
By the way, I had difficulties with the higher order elements which behavior can be replicated with the shoebox2d eigen case (or may be this is caused by some problem with my system?)
When this case run with Mumps and "element = p:2" for both wave and NS solver there is a crash with the following message:
"EigenSolve: .. ** On entry to DLASCL parameter number 4 had an illegal value
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_OVERFLOW_FLAG"
With p:3, same. If one of them p:2 and other p:1 working and solves etc.
For 3D case this behavior is different:
both solvers with p:2 crashes with segmentation fault. It works when both p:3 etc.
As a result I was not able to get any usable result with solid in water fsi problem yet.
-
- Site Admin
- Posts: 4812
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: eigenFsi
Hi
You're right. This does not work correctly ;-<
What has been tested extensively is harmonic coupling between Helmholtz and StressSolver. Also coupling for eigen analysis between ShellSolver and StressSolver should work. Technically also WaveSolver and StressSolver coupling works for eigenmodes but unfortunately the results are just plain wrong. The coupling matrix in FSI case should be modified for this case as well. I'm having a look at this just now and I think I'm close but still not quite there yet....
Maybe you could share your test case and the reference.
-Peter
You're right. This does not work correctly ;-<
What has been tested extensively is harmonic coupling between Helmholtz and StressSolver. Also coupling for eigen analysis between ShellSolver and StressSolver should work. Technically also WaveSolver and StressSolver coupling works for eigenmodes but unfortunately the results are just plain wrong. The coupling matrix in FSI case should be modified for this case as well. I'm having a look at this just now and I think I'm close but still not quite there yet....
Maybe you could share your test case and the reference.
-Peter