Brainstorming about mesh adaptivity

[GuillermoCasas]

I'm opening this issue to start a discussion, especially within the @KratosMultiphysics/implementation-committee, about the design that @RiccardoRossi and I speculated about some days ago related to #4594 and #4558. Here is the sketch of a pseudocode for modifying the analysis_stage (very rough):

======== ORIGINAL ==============

def RunSolutionLoop(self):
    """This function executes the solution loop of the AnalysisStage
    It can be overridden by derived classes
    """
    while self.KeepAdvancingSolutionLoop():
        self.time = self._GetSolver().AdvanceInTime(self.time)
        self.InitializeSolutionStep()
        self._GetSolver().Predict()
        is_converged = self._GetSolver().SolveSolutionStep()
        self.__CheckIfSolveSolutionStepReturnsAValue(is_converged)
        self.FinalizeSolutionStep()
        self.OutputSolutionStep()

---

def RunSolutionLoop(self):
    """This function executes the solution loop of the AnalysisStage
    It can be overridden by derived classes
    """
    while self.KeepAdvancingSolutionLoop():
        StorePullBackInformation  - Check Pointing

        AdvanceTime
        InitializeSolutionStep
        Predict

        success = SolveSolutionStep
        if(not success): ## --> time adaptivity
            reduce time step
            pull back solution to the end of the previous step
            goto 25 (antes del AdvanceInTime)

        if(remeshing is needed)
            remesh (in what configuration? what do i need to interpolate? )
            if(in old configuration - Tot Lagrangian)
                pull back solution to the end of the previous step
            if(redo all step)
               goto 25
            else
               goto 29

        FinalizeSolutionStep

        output

---

def RunSolutionLoop(self):
    """This function executes the solution loop of the AnalysisStage
    It can be overridden by derived classes
    """
    while self.KeepAdvancingSolutionLoop():

        StorePullBackInformation  - Check Pointing
        dt = ChooseTimeStep
        AdvanceInTime(dt, clone_time_step)
        do_initialize_and_predict = True

        while(not success):
            if(do_initialize_and_predict):
                InitializeSolutionStep()
                Predict

            success = SolveSolutionStep(...)

            redo_initialize_and_predict = AdaptSpaceAndTime(success)
                --> calls internally LoadCheckpoint() ##pull back
                --> adapt time step

        FinalizeSolutionStep

        output

[rubenzorrilla]

Thanks for reporting this @GuillermoCasas . I found that the last option would be more easy to be understood by the users, as it is clear that the adaptivity is done until convergence is reached.

One comment, if mesh adaptivity needs to be done according to other criterias (e.g. where there is a plastic region or close to the level set), how would we fit this into these designs?

Thanks!

[loumalouomega]

@GuillermoCasas what you propose adds more steps to the process, but some of those steps are right now included in remeshing processes like the mmg. There the interpolation is done and the lagrangian-eulerian framework is considered. Additionally lacks several things that my original proposal included, like the possibility of remeshing before the solution loop or before/after the solution loop depending of the needs.

El sáb., 30 may. 2020 9:22, Rubén Zorrilla notifications@github.com escribió:

Thanks for reporting this @GuillermoCasas https://github.com/GuillermoCasas . I found that the last option would be more easy to be understood by the users, as it is clear that the adaptivity is done until convergence is reached.

One comment, if mesh adaptivity needs to be done according to other criterias (e.g. where there is a plastic region or close to the level set), how would we fit this into these designs?

Thanks!

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/issues/6992#issuecomment-636290776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAHCL54YHTGK4PMDWBTRUCW2HANCNFSM4NOCUP6Q .

[GuillermoCasas]

Thanks for reporting this @GuillermoCasas . I found that the last option would be more easy to be understood by the users, as it is clear that the adaptivity is done until convergence is reached.

One comment, if mesh adaptivity needs to be done according to other criterias (e.g. where there is a plastic region or close to the level set), how would we fit this into these designs?

Thanks!

Well, in principle the function AdaptSpaceAndTime could do all sorts of checks, including the ones you mention. Right?

[GuillermoCasas]

@GuillermoCasas what you propose adds more steps to the process, but some of those steps are right now included in remeshing processes like the mmg. There the interpolation is done and the lagrangian-eulerian framework is considered. Additionally lacks several things that my original proposal included, like the possibility of remeshing before the solution loop or before/after the solution loop depending of the needs. El sáb., 30 may. 2020 9:22, Rubén Zorrilla notifications@github.com escribió: … Thanks for reporting this @GuillermoCasas https://github.com/GuillermoCasas . I found that the last option would be more easy to be understood by the users, as it is clear that the adaptivity is done until convergence is reached. One comment, if mesh adaptivity needs to be done according to other criterias (e.g. where there is a plastic region or close to the level set), how would we fit this into these designs? Thanks! — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#6992 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYQZAHCL54YHTGK4PMDWBTRUCW2HANCNFSM4NOCUP6Q .

First of all, please do not consider this initial skech as a firm proposal. It is only a template to evolve a better design. That was the idea.

About other packages including some of these processes, I think this is not all that problematic. What is problematic right now is to have a design that is too rigid.

About it lacking the possibility to remesh before, yes, I was aware of that, but @RiccardoRossi very strongly supports the idea that the boundary conditions must be all set in the InitializeSolutionStep and only there. Is this not a problem?

By the way, the role of the various public functions in AnalysisStage are not well documented in the corresponding page in the Wiki. I think this is problematic, since people do not agree on their role.

Well, I hope this thread is useful for advancing an abstract framework that is general enough. I have now become personally interested in this and willing to spend some time in the idea.

[loumalouomega]

BC are set only in InitializeSolutionStep, but processes must be reinitialized anyway, otherwise some processes may fail if their member variables were set on the initial configuration

[GuillermoCasas]

Yes. Then perhaps the function InitializeSolutionStep should be broken down. One should be able to call 'ApplyBoundaryConditions' and not be forced to call self._GetSolver().InitializeSolutionStep().

[adityaghantasala]

@loumalouomega why is it that BC are set only set InitializeSolutionStep ?

[RiccardoRossi]

@loumalouomega why is it that BC are set only set InitializeSolutionStep ?

that's the rule...BCs are set by the processes in the InitializesolutionStep function

[adityaghantasala]

Exactly ! @loumalouomega following this I think there should also be a rule like that defining where re-meshing should happen. There cannot be some processes/strategy doing re-meshing before solution loop or before/after solution loop.

[adityaghantasala]

@RiccardoRossi Saying that I completely agree that BC should be set in InitializeSolutionStep and it is not a problem but something that will define a clear workflow without any confusions.

[loumalouomega]

Exactly ! @loumalouomega following this I think there should also be a rule like that defining where re-meshing should happen. There cannot be some processes/strategy doing re-meshing before solution loop or before/after solution loop.

Why not?, this does not change that the BC are set in the InitializeSolutionStep

[RiccardoRossi]

@loumalouomega can u explain what is the usecase in which it is obligatory to do either before or after?

[adityaghantasala]

Why not?, this does not change that the BC are set in the InitializeSolutionStep

I am taking the application of BC as an example here ..

[loumalouomega]

After is when you perform the remesh with the resulting information of the current step (which is done in almost all my implementations), before when you use the information available at the beginning of one step, is not the same. The important thing is that BC are set only in InitializeSolutionStep

[rubenzorrilla]

@KratosMultiphysics/technical-committee has briefly discussed about this. What we suggest goes in the line of @GuillermoCasas design. Long story short we should have our own intermediate layer to interface the MMG (and possibly other) library.

Having said this, we propose following the re-meshing discussion in this thread and closing the related PR. @loumalouomega we strongly appreciate your effort on this, so let's keep your branches alive for future developments based on this discussion.