Open rubenzorrilla opened 5 years ago
Hi @rubenzorrilla and @adityaghantasala My proposal for the ProjectParameters > solver_settings is the following:
"solver_settings": {
"implementation": "MPC",
"model_part_name": "FluidModelPart",
"domain_size": 2,
"solver_type": "Monolithic",
"model_import_settings": {
"input_type": "mdpa",
"input_filename": "test_chimera"
},
"echo_level": 0,
"compute_reactions": false,
"maximum_iterations": 10,
"relative_velocity_tolerance": 0.001,
"absolute_velocity_tolerance": 1e-5,
"relative_pressure_tolerance": 0.001,
"absolute_pressure_tolerance": 1e-5,
"linear_solver_settings": {
"solver_type": "ExternalSolversApplication.amgcl",
"max_iteration": 200,
"tolerance": 1e-7,
"provide_coordinates": false,
"smoother_type": "ilu0",
"krylov_type": "gmres",
"coarsening_type": "aggregation",
"scaling": false
},
"volume_model_part_name": "Parts_both_surfaces",
"skin_parts": [
"AutomaticInlet2D_inlet",
"Outlet2D_outlet",
"NoSlip2D_cross",
"NoSlip2D_top",
"NoSlip2D_bottom"
],
"no_skin_parts": [],
"chimera_parts": [
{
"model_import_settings":{
"input_type": "mdpa",
"input_filename": "patch1"
},
"model_part_name": "GENERIC_background_surface",
"model_part_inside_boundary_name": "GENERIC_back_ground_boundary",
"overlap_distance": 0.01
},
{
"model_import_settings":{
"input_type": "mdpa",
"input_filename": "patch2"
},
"model_part_name": "GENERIC_patch_surface",
"model_part_inside_boundary_name": "NoSlip2D_cross",
"overlap_distance": 0.7
}
],
"time_stepping": {
"automatic_time_step": false,
"time_step": 0.01
},
"formulation": {
"element_type": "vms",
"use_orthogonal_subscales": false,
"dynamic_tau": 1.0
}
}
As you can see, I've added the chimera_parts inside solver_settings, and the patches can be loaded from separated mdpa files, so each path has one mdpa.
This way, the background mesh is the Fluid itself, and the main domain does not need to be remeshed if a new patch is loaded.
What do you think?
+1 for adding chimera_parts in the solver settings. I will make the necessary changes in the implementation to use that. secondly a question : I do like the idea of using separate mdpas for patches. But am now sure if I understand how to merge all those loaded modelparts into one ! This is because the Chimera formulation needs all (background and patches) to be in pne single modelpart and this is used for solution.
Also the parameter
"implementation": "MPC",
is not needed anymore.
+1 for adding chimera_parts in the solver settings. I will make the necessary changes in the implementation to use that. secondly a question : I do like the idea of using separate mdpas for patches. But am now sure if I understand how to merge all those loaded modelparts into one ! This is because the Chimera formulation needs all (background and patches) to be in pne single modelpart and this is used for solution.
I think that if we write the .mdpa's as we do in the FSI app (with no repeated ids.) it think it should be possible to read them one by one and add them to the same model part.
Ok .. Then @jginternational I have no objection if they are written different mdpa files with their respective submodelparts. But this means the advantage that @jginternational says that is not requiring to remesh is not anymore present right .. one has to load the whole .gid and then edit it ?
I thought everything has to me in one mdpa because of the fluid solver? => volume_model_part?
@philbucher we can combine them in the chimera solver. It should not be a problem. Why I am interested in doing this is the flexibility of having the possibility of meshing background and patches differently. If what @jginternational is proposing does not give this ... I think we should not do it.
Why I am interested in doing this is the flexibility of having the possibility of meshing background and patches differently.
Actually to have capability is what @jginternational and me discussed yesterday. We just wanted your confirmation to carry on the developments.
We will provide you with a GUI test case once these features are implemented so you can update the solver accordingly. Furthermore, we will save the cross section case you sent me as predefined example.
Actually to have capability is what @jginternational and me discussed yesterday. We just wanted your confirmation to carry on the developments.
I definitely love to have such capability. But before that, I suggest a short skype call to completely be on the same page.
We will provide you with a GUI test case once these features are implemented so you can update the solver accordingly. Furthermore, we will save the cross section case you sent me as predefined example.
Perfect ! . The cross section is a nice example. We can use it. How difficult is it to change later on ?
Actually to have capability is what @jginternational and me discussed yesterday. We just wanted your confirmation to carry on the developments.
I definitely love to have such capability. But before that, I suggest a short skype call to completely be on the same page.
Fine for me. @jginternational do you have any date & time constraint?
We will provide you with a GUI test case once these features are implemented so you can update the solver accordingly. Furthermore, we will save the cross section case you sent me as predefined example.
Perfect ! . The cross section is a nice example. We can use it. How difficult is it to change later on ?
This would depend on the patch geometry... The nice point is that you can record macros in .tcl while drawing the geometry in GiD so you can open the code it creates and paste it in the example script. Thus, for simple geometries (the ones you can generate by using the GiD sketch tools) it should be more or less straightforward thanks to this trick.
After speaking with @adityaghantasala, the TODOs for the json are:
implementation
flag in solver_settings
.chimera
section in the end part of the .json file.Regarding the GUI, it looks OK. The unique thing missing is to make it possible that the user selects the model_part_inside_boundary_name
. This is the interior boundary of the patch. The exterior boundary of the patch is automatically found by the solver.
This would imply to assign two GiD groups when creating one Chimera Parts
in the interface. @jginternational any hint?
Regarding the GUI, it looks OK. The unique thing missing is to make it possible that the user selects the
model_part_inside_boundary_name
. This is the interior boundary of the patch. The exterior boundary of the patch is automatically found by the solver.This would imply to assign two GiD groups when creating one
Chimera Parts
in the interface. @jginternational any hint?
We found a solution to circumvent this if we create a new Chimera boundary
in the Conditions
sections. Then we do a list of Chimera boundaries in the json so @adityaghantasala can loop it to mark such Chimera boundaries.
This is a reminder to keep the new Chimera GUI development alive.
I'm attaching a reference test case that @adityaghantasala sent to me. chimera_cross_test_case.zip