Kratos
Kratos copied to clipboard
[SeveralApps] Improving and adding missing python scripts for adaptive remeshing
This adds some missing scripts fro adaptive remeshing. Specially the analysis for FluidDynamicsApplication
(This is in order to make the examples on the Examples repository to work and specially in order to make easier to correct/update in the future)
I have a couple of comments related to the imports I would push directly to this branch (tomorrow) if this is ok for you
But run the examples in the examples repository. If your concern is that the MeshingApplication is imported I can tell you that without it cannot find the MMG_process.py
El dom., 31 mar. 2019 19:10, Philipp Bucher [email protected] escribió:
I have a couple of comments related to the imports I would push directly to this branch (tomorrow) if this is ok for you
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/pull/4558#issuecomment-478359746, or mute the thread https://github.com/notifications/unsubscribe-auth/ATEMgLPOF8PtfviyamCtoOxMP6nEaFq2ks5vcOvngaJpZM4cUaEU .
Ok I will check
I cleaned the imports, there were many unused ones
I also checked the examples and pushed some corrections, now they should work also without importing the MeshingApp
I don't have mmg yet, could you please test the cases you are concerned about? The tests in Kratos are running
Note: import python_script will stop working at some point, the safe way is to add the application-name like this: from kratos.AppName.python_script as py_script
=> this also imports the application
I cleaned the imports, there were many unused ones
I also checked the examples and pushed some corrections, now they should work also without importing the MeshingApp
I don't have mmg yet, could you please test the cases you are concerned about? The tests in Kratos are running
Note:
import python_scriptwill stop working at some point, the safe way is to add the application-name like this:from kratos.AppName.python_script as py_script=> this also imports the application
I will
I cleaned the imports, there were many unused ones I also checked the examples and pushed some corrections, now they should work also without importing the MeshingApp I don't have mmg yet, could you please test the cases you are concerned about? The tests in Kratos are running Note:
import python_scriptwill stop working at some point, the safe way is to add the application-name like this:from kratos.AppName.python_script as py_script=> this also imports the applicationI will
It works fine
Why it is needed to have a different analysis stage for remeshing?
Because if you remesh you need to reinitialize everything, maybe we can integrate the remeshing into the base analysis stage (if ModelPart is modified then reinitilize the whole system)
Why it is needed to have a different analysis stage for remeshing?
Because if you remesh you need to reinitialize everything, maybe we can integrate the remeshing into the base analysis stage (if ModelPart is modified then reinitilize the whole system)
hm I am not sure abt this ... This is quite specific to problems with a mesh What abt DEM, MPM etc?
Also the current solution is too messy imo to go mainstream
Why it is needed to have a different analysis stage for remeshing?
Because if you remesh you need to reinitialize everything, maybe we can integrate the remeshing into the base analysis stage (if ModelPart is modified then reinitilize the whole system)
This is my point, I'd go for a common (as common as possible as @philbucher says) rather than adding new analysis stage files to all the apps.
Why it is needed to have a different analysis stage for remeshing?
Because if you remesh you need to reinitialize everything, maybe we can integrate the remeshing into the base analysis stage (if ModelPart is modified then reinitilize the whole system)
This is my point, I'd go for a common (as common as possible as @philbucher says) rather than adding new analysis stage files to all the apps.
Agree, but modifying the base analysis requires an agreement of many people, which may be not possible. I can in this PR unify the derived analysis, and we can have a discussion about to include it on the base class
before modifying the AnalysisStage I would recommend to first collect the necessary operations in a common utility-file in the core, this way you reduce the duplication significantly
As I said before, I am not sure if the remeshing stuff can go into the base-class, since it is not applicable for all simulations
before modifying the
AnalysisStageI would recommend to first collect the necessary operations in a common utility-file in the core, this way you reduce the duplication significantlyAs I said before, I am not sure if the remeshing stuff can go into the base-class, since it is not applicable for all simulations
Yes, that was what I meant
I updated for now only the Fluid, if you agree I will do the same for the other analysis
dexription is missing There are desciptions
please use the new method from the baseclass
What do you mean?
If you remesh, no matter what, you need to restart all, because some strategies assume sizes on rhs and lhs and may have issues. (except if you do after reading and just before the initialize)
El lun., 1 abr. 2019 22:04, Rubén Zorrilla [email protected] escribió:
@rubenzorrilla commented on this pull request.
In applications/FluidDynamicsApplication/python_scripts/adaptative_remeshing_fluid_dynamics_analysis.py https://github.com/KratosMultiphysics/Kratos/pull/4558#discussion_r271028783 :
- It can be imported and used as "black-box"
- """
- def RunSolutionLoop(self):
"""This function executes the solution loop of the AnalysisStageIt can be overridden by derived classes"""# If we remesh using a processcomputing_model_part = self._GetSolver().GetComputingModelPart()root_model_part = computing_model_part.GetRootModelPart()while self.time < self.end_time:self.time = self._GetSolver().AdvanceInTime(self.time)# We reinitialize if remeshed previouslyBut this means that you might do the re-meshing before and after the InitializeSolutionStep(). When does this have sense? If the re-meshing is to be done once, and we want to call it as a process, I'd rather go for a interval-type solution as we use in the processes.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KratosMultiphysics/Kratos/pull/4558#discussion_r271028783, or mute the thread https://github.com/notifications/unsubscribe-auth/ATEMgObM5lqYGnRcBSSfab--O29bWNL3ks5vcmY-gaJpZM4cUaEU .
…
I know this... What I'm asking is in which situation you might want to remesh before and after the InitializeSolutionStep()?
…
I know this... What I'm asking is in which situation you might want to remesh before and after the InitializeSolutionStep()?
If you want to remesh during simulation the proper thing to do is do it after the initialize, man y variables, BC's and so on are assigned during the InitializeSolutionSTep. If you want to preserve them you need to do it just after
The comments have been addressed @philbucher @rubenzorrilla
Our comments yes, but you are missing the approval from @KratosMultiphysics/technical-committee since this PR significantly changes important functionalities
Our comments yes, but you are missing the approval from @KratosMultiphysics/technical-committee since this PR significantly changes important functionalities
OK
In my opinion this capability should be implemented in the base analysis/solver. I just cannot see how our abstract classes are general enough if they cannot include remeshing naturally.
However, I this way of extending the capabilities of the base classes (through a function wrapper) can work as a way to test them before they can be added to the base classes.
In my opinion this capability should be implemented in the base analysis/solver. I just cannot see how our abstract classes are general enough if they cannot include remeshing naturally.
However, I this way of extending the capabilities of the base classes (through a function wrapper) can work as a way to test them before they can be added to the base classes.
I agree with you; I can do some refactor, but then it will affect everyone...
In my opinion this capability should be implemented in the base analysis/solver. I just cannot see how our abstract classes are general enough if they cannot include remeshing naturally.
However, I this way of extending the capabilities of the base classes (through a function wrapper) can work as a way to test them before they can be added to the base classes.
Agree, the @KratosMultiphysics/implementation-committee waits for the point of @adityaghantasala to reach a consensus
Ping @adityaghantasala
The changes proposed by @adityaghantasala should be implemented before we approve this PR.
@adityaghantasala I addressed your comments
i think this is interesting, nevertheless i think i need some explanations. @loumalouomega let's organize a meeting so that you explain me a bit the design. Of course let's make it so that anyone interested can join.
i think this is interesting, nevertheless i think i need some explanations. @loumalouomega let's organize a meeting so that you explain me a bit the design. Of course let's make it so that anyone interested can join.
OK
I would like to join the meeting