[Core][Element/Condition] using const

[philbucher]

this is a new, BACKWARD COMPATIBLE attempt to #2993, for now only a draft and not all the changes to discuss if this is the way to go

=> adv: Backwardcompatible, disadv: the compilation is full of deprecation warnings. Updating the code in the derived classes is easy but at least for some days we would have many warnings

Tests seem to still be working, so I guess this solution would be ok

One way to go would be to add the deprecation-warnings only after some time.
This would give the developers time to adapt

[philbucher]

@KratosMultiphysics/technical-committee This is ready to be reviewed

Note that the new functions are in most places NOT being called, since the scheme still passes on a non-const ProcessInfo and hence directly the old functions will be called
The schemes will be adapted in the next PR, after this the developers can start adapting their elements/conditions

[philbucher]

@maceligueta it seems like there already is a function Initialize in a DEM-element:

/home/travis/build/KratosMultiphysics/Kratos/applications/DEMApplication/custom_elements/spheric_particle.h:134:14: error: ‘virtual void Kratos::SphericParticle::Initialize(const Kratos::ProcessInfo&)’ can be marked override [-Werror=suggest-override]
 virtual void Initialize(const ProcessInfo& r_process_info);

how is this currently used?

[philbucher]

Ping @maceligueta @KratosMultiphysics/dem

[philbucher]

ping @maceligueta @KratosMultiphysics/dem

[maceligueta]

Hi @philbucher , sorry about the delay. Many years ago we decided to create an Initialize method with the ProcessInfo inside. The elements call this function after they are created. However, as you can imagine, we needed to downcast in order to call this function (and a few others). The fact that the Discrete Elements are so different from Finite Elements was limiting our options very much, so we opted for the downcasting, knowing that it's not an ideal solution. Neither it is computing discrete elements with a Finite Elements code.
But right now this is a good change for us, we can override the new method and loop over Elements instead of looping over SphericParticles. Not a big gain for us, because we do the downcasting for other methods, but still going in a better direction.
I don't know if this answers your question...

[philbucher]

@maceligueta thanks, this is what I suspected
I guess I can just add the override then (this is why travis fails) or do you have concerns this would not work?

[maceligueta]

No concerns. I think it should work if you just add the override.

[philbucher]

It seems to work now
Ping @KratosMultiphysics/technical-committee

[philbucher]

@maceligueta I guess this can be removed afterwards

[maceligueta]

sure! Should I?

[philbucher]

I think it is better to do it in a future PR, this one is already large and contains delicate changes

[philbucher]

@KratosMultiphysics/technical-committee now that we have sorted out some larger things, I would like to take a look at this again, since I think this is quite a necessary cleanup.

[pooyan-dadvand]

@KratosMultiphysics/technical-committee: 👍

[pooyan-dadvand]

Just for the record:

This will be followed by another PR changing the scheme to use the added methods with const ProcessInfo and then all developers should adapt their own elements and conditions.

[pooyan-dadvand]

👍

[philbucher]

merging such that I can proceed with the porting

[philbucher]

please wait with implementing this in your code, there will be a followup-PR, with which this PR will become fully available