Struggling with SpeedOfSound management ...

[pbouda95]

Hello,

As a user of the MaterialDataManager class through fortran bindings, I am trying to handle the @SpeedOfSound from the solver point of view.

First, I did not manage to find a crystal clear explanation about its features in the documentation so I looked at the Doxygen (in include/MGIS/Behaviour/Behaviour.hxx). It says that you need to activate a flag trough the first component of the tangent operator array (must be > 50). However, my implementations did not succeed so I am wondering if I am doing something wrong here.

Does anybody have a clue on it ?

Cheers,

[thelfer]

Hi @pbouda95,

It says that you need to activate a flag trough the first component of the tangent operator array (must be > 50).

This is true when using MGIS to integrate a mechanical behaviour on a single integration point.

For several integration points (managed by the MaterialDataManager class), the speed of sound can be computed in C++ and python using overloaded versions of the integrate function which takes a data structure named BehaviourIntegrationOptions as argument (in place of the IntegrationType enumeration type used so for).

Unfortunately, this data structure (BehaviourIntegrationOptions) and the associated overloaded versions of the integrate function are currently not wrapped in C nor in fortran.

[pbouda95]

Hi @thelfer,

Thanks for the quick answer.
Aside from the fact that some C and Fortran wrappers are missing for a few objects/functions, do you see any additional loopholes ? If not, I am pretty much motivated to contribute and write them.

Thanks,

[thelfer]

do you see any additional loopholes

I don't see any :)

[pbouda95]

Hello @thelfer,

I will provide the missing bindings ASAP. However there is still something which bothers me: What about the way to provide the mass density at the reference configuration ? I did not see any information about that.

One solution might be to push it through an ExternalStateVariable but I am not sure if it is what it was scheduled ...

Thanks,

[thelfer]

You're right. The mass density is not passed right now !

[thelfer]

@pbouda95 branch 121-pass-the-mass-density-from-the-materialdatamanager contains a first implementation that may provide the wanted feature. It seems that a memory fault may happen from time to time, although valgrind does not report anything useful.

So it's mostly a work in progress, but you can start playing with it and consider porting the tests ComputeSpeedOfSoundTest and ComputeSpeedOfSoundTest2 to fortran