Kratos: Custom GiD problemtypes should eventually be moved out of Kratos

[philbucher]

Description
The @KratosMultiphysics/technical-committee discussed about the custom gid problemtypes that exist in some applications should eventually be moved out of Kratos.
We are not sure if they comply with the structure of the main GiD-interface so we would like to initiate the discussion of where and how to but those interfaces

Pinging the devs that are affected by this: @KratosMultiphysics/dem @AlejandroCornejo @miguelmaso @ipouplana

[AlejandroCornejo]

Hi! Yes, i do have my custom ptype for my App. Why is it necessary to remove this files? Is it because of the size?

[AlejandroCornejo]

In fact I feel kind of forced to do something (erasing my ptype) that is not optimal for me. What has changed since it was allowed to have a custom ptype in your personal Kratos App?
Do not misunderstand me, I can erase my ptype from the repo but, since it is suboptimal for me (have two repos or send my ptype to whoever uses my app), I would like to discuss the pros of this new approach.

[philbucher]

In fact I feel kind of forced to do something

Thats why this is a discussion, we are also not sure what is the optimal solution

There are several reasons:

• We have a repository for the GiD interface which hosts most apps. => we would like to hear the reasons why is is not in there?
• We want to avoid mixing the Solver (Kratos) with certain preprocessors
• The size is indeed an issue, bcs oftentimes also examples are included which are large
• What has changed since it was allowed to have a custom ptype in your personal Kratos App? I think this is mostly legacy, there was never a discussion about where they should be => hence this issue
• More apps are planning to add this and we want to discuss beforehand how to preceed

[ipouplana]

Hello @philbucher ,
I think these custom GiD problemtypes (at least mine) do not follow at all the same structure as the main GiD-interface and, although I guess they could be updated to be like the main GiD-interface, it is not an easy task and, in my opinion, has little reward. I am sure there are good reasons for updating them into the new style, but the thing is that these problemtypes are simple and work well...
Then, one possibility could be to store them in the GiDInterface repo without having to update them to the current standard... We could have a folder for the old problemtypes. What do you think?

[AlejandroCornejo]

Hello @philbucher ,
I think these custom GiD problemtypes (at least mine) do not follow at all the same structure as the main GiD-interface and, although I guess they could be updated to be like the main GiD-interface, it is not an easy task and, in my opinion, has little reward. I am sure there are good reasons for updating them into the new style, but the thing is that these problemtypes are simple and work well...
Then, one possibility could be to store them in the GiDInterface repo without having to update them to the current standard... We could have a folder for the old problemtypes. What do you think?

I agree with @ipouplana. I can accept to be within the Kratos Ptype in some "research" folder ptype or something similar.

[miguelmaso]

I also agree with @ipouplana and @AlejandroCornejo

[maceligueta]

The @KratosMultiphysics/dem team is addressing this in PR #7788

[maceligueta]

Hello @philbucher ,
I think these custom GiD problemtypes (at least mine) do not follow at all the same structure as the main GiD-interface and, although I guess they could be updated to be like the main GiD-interface, it is not an easy task and, in my opinion, has little reward. I am sure there are good reasons for updating them into the new style, but the thing is that these problemtypes are simple and work well...
Then, one possibility could be to store them in the GiDInterface repo without having to update them to the current standard... We could have a folder for the old problemtypes. What do you think?

The GiDInterface repository seems to be thought to contain a single ProblemType which works for many applications. I would say it's better if we put these other ProblemTypes in a different repository, or even one repository for each ProblemType. I am thinking that the DEM Team can have a repository for the old ProblemTypes, @AlejandroCornejo can hold his own ProblemType, @ipouplana his own, or distributed in teams. Truth is that someone who wants to download @AlejandroCornejo 's GUI does not want to download DEM's GUI in general.

[ipouplana]

If GiDInterface repo is designed to contain a single problemtype, then I agree with @maceligueta that the best option is to move our problemtypes to other repos. As @AlejandroCornejo said, this is not optimal, but it's actually cleaner.

[jginternational]

After the long read, let me explain some things:

The current GiDInterface repository is called to be "the official" gid interface, so it's the one that will be "delivered" via GiD internet retrieve, and it's where new apps should appear, following the 'new system'.
This repository is structured as a single problemtype that hosts several applications BUT inside those apps, there is freedom to implement whatever the developer wants. It's true that the current apps are developed following the new 'framework' to make things easier, but we have done in the past an integration with "old kratos gui" problemtypes, and things worked. Let me show an example:

Time travel to May 2017:
In the begining of this new system, I implemented Fluid, Solid and Structural apps, following the new 'system'. The DEM team wanted to appear in the interface but their problemtype was still the old one. The user could click on DEM app in the new problemtype, and the 'old' one was loaded.
References:
https://github.com/KratosMultiphysics/GiDInterface/commit/c4588977c01cc8d916b911d085809595e9d63f23#diff-8d5b9e28801c2812b7b3fc161d81a8da301f295b448a913043f1dad2af44b2a1

We can achieve this in 2 ways:

• A: Copying those custom problemtypes as new apps in the GUI, (I mean copy the files and pushing them to the repo)
• B: Use a single and independent repository for each of those custom problemtypes, and use the concept of git submodule to have the gui updated.

In my opinion, A is a dirty solution, since brings old code to the new problemtype (most of the code of the old problemtype will be the same, but we can not make them share it). and B forces me to learn and handle the submodules (No pain, no gain...)

Another solution is to create independent repositories and don't link them to the general GUI, but that does not affect me.

EDIT 1: This does not mean that everything contained in the GIDInterface repository will be published, if we bring those custom problemtypes to this repo, the can appear in the release, or not, depending on several factors.