KratosMultiphysics / GiDInterface

The graphical user interface of Kratos for GiD. Featuring CFD, CSM, DEM, PFEM, etc
Other
31 stars 16 forks source link

Chimera GiD GUI #597

Open rubenzorrilla opened 5 years ago

rubenzorrilla commented 5 years ago

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

jginternational commented 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?

adityaghantasala commented 5 years ago

+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.

adityaghantasala commented 5 years ago

Also the parameter

"implementation": "MPC",

is not needed anymore.

rubenzorrilla commented 5 years ago

+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.

adityaghantasala commented 5 years ago

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 ?

philbucher commented 5 years ago

I thought everything has to me in one mdpa because of the fluid solver? => volume_model_part?

adityaghantasala commented 5 years ago

@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.

rubenzorrilla commented 5 years ago

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.

adityaghantasala commented 5 years ago

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 ?

rubenzorrilla commented 5 years ago

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.

rubenzorrilla commented 5 years ago

After speaking with @adityaghantasala, the TODOs for the json are:

rubenzorrilla commented 5 years ago

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?

rubenzorrilla commented 5 years ago

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.