kratos core-lite

[josep-m-carbonell]

There is a large number of classes and features located in kratos core that are only there for the specific usage of an application or a reduced number (1 to 3) of applications. An exhaustive analysis can be done to check what is really useful and must be shared by almost all applications and what can be classified as a specific usage.

Have you considered at some point, to have a reduced version of kratos core, only with the Model and the objects it contains? A kratos-lite which reduces the compilation time, the possible compilation problems when used in the different OS.

This also would give flexibility to the development of the applications.

To make a bit of criticism: Now a lot of pull-requests are based adding new features to the core, some developers act as if they owned the place thinking that what they do is valid for everyone. Maybe, you must think to add something to the core if it is mature and general enough. Also this type of changes #2194 . Do you have a list of what names are not consistent and appropriate? Possibly this change is needed, but this is the way to do it?, how and when can others be changed?...

I say that because the core can be cleaned in a kratos-lite version and could be controled in a easier way.

@KratosMultiphysics/team-maintainers @KratosMultiphysics/solid-mechanics @KratosMultiphysics/pfem

[loumalouomega]

I was thinking the same, despite of being one of the developers that finds that if something can be use across several applications it should be on the core. But it is true that if for example we want to make developments on the IoT and compile it on a Raspberry Pi the current size of the core will make impossible.

The thing is that we still have pendent to separate Kratos on Core, Core Applications and Sandbox Applications. One more iteration would be separate into this CoreLite and CoreExtended let's say.

I will mention other groups interested @KratosMultiphysics/structural-mechanics @KratosMultiphysics/fluid-dynamics

[loumalouomega]

In any case refactor the Core implies a lot of work, and is not an easy task, and will break many retro-compatibilities.

[loumalouomega]

Besides, the blog of CPPdepend explains perfectly all the problems derived from designing a code, legacy code, designing as modular, etc, etc... https://cppdepend.com/blog/

I think this discussion is an easy one, and we need to agree all of us.

[josep-m-carbonell]

Thank you for your comments @loumalouomega, I do not know exactly what part of the blog of CPPdepend do you make reference. However it will be great if the @KratosMultiphysics/technical-committee expose their ideas about the possibility of have a Kratos CoreLite and CoreExtended (that can be CoreLite + CoreApps) parts.

[maceligueta]

I find that making the core lighter is a good idea in general, but in my opinion, not really prioritary. Apparently, it would make life easier for some developers (less compilation time) but harder for those who need a big variety of objects and would need to import many applications (so finally the compilation time would be the same, and the code would be more complex). So I agree that it would bring advantages, but no so drastic, and not so urgent (just my opinion).

[josep-m-carbonell]

Thank you for you comments @maceligueta. Let me ponder your arguments. If you talk about what is a priority without mentioning other priorities you are being deceptive, indirectly it can be understood as it is not important. The same happens with the words drastic and urgent. One thinks, where is the fire? If there is no fire, then it doesn't matter. Let's forget this.

In fact, I think it is burning but you can not see the fire. I say that for something you have also mentioned. There are some developers that have extented needs of several implementations and they force others to carry with them. That happens when the objects are implemented in the core. Some developers use the core as if they owned the place, they put the things in the core because it is easier and the arguments they use are always the same: now this object is only used by my application but I locate it in the core because it will be available to everyone. The only certainty is that from now on everyone will have to compile it.

Programming in the core is also used to keep the control of a type of implementation. Giving automatically the attribute of this is the standard and better than other implementations outside of the core. Sometimes this is good, others is not so good.

It is clear that that if you need everything you must compile everything, but you also agree that in all other cases, making it lighter is an advantage.

Now, we only need to know what subjects are in the list of good ideas to determine the level of priority it can be assigned to this one.

[maceligueta]

Just taking a look at the other 69 pending issues (or the 16 on-going projects) can give you a glance of some candidates that might be approached with more urgency by anyone who has to (or wants to) dedicate time to this. But of course it is a matter of opinions. Having said this, I think that the expression 'own the place' is offensive here. If you consider that some pull requests are going in a wrong direction, I would suggest you to comment your technical reasons in each specific pull request, in such a constructive way that the project moves forward. Another possibility is to create a new Issue proposing specific changes in the core that can be discussed, as many people do, and it would be great if all of us avoid discrediting other developers.

[josep-m-carbonell]

If somebody is feeling offended by my comments I am sorry for that, it was not my intention to discredit anybody. We were talking about how the evolution of the core is going on and how to improve it. I think all developers do their best working in this project. Reduce the core size is not a matter of a what happens in a new pull request. Most of the things are already there.

If you ask for being constructive, think that the most constructive way of facing an issue like this is not saying: we have other things more important than this... It seems you are despicing it and discrediting the proposal. I think it would be better to propose something like: a list of objects of the core (that can be considered not so general) can be identified and classified in order to relocate them in a proper place and face a possible reduction of the core size in the future. This is something that needs to be done in agreement and the contribution of everybody working with those parts of the code.

[RiccardoRossi]

on my side, i believe that the core is there to "set the rules" so it is the correct place for "standardization" of things that CAN be used in multiple places. the idea is that such rules should be negociated, and ideally "the best" possible. If this is not so, than they can be adjusted once an agreement is found, but they are valid as long as this does not happen (exactly to avoid that someone "owns the place")

having said this, if we are made aware of things that should be removed for a well argumented reason, than i think an agreement can be quite easily negociated on a case to case basis.

let me note that from the semantic point of view, the use of the formula "need to" is too strong in this context (and sounds rather aggressive). if you want to suggest something which represents a personal opinion (fair, not telling the contrary) than the formula employed should express some sort of doubt, like "could be". Doing so would sound kinder to people reading. i could make some other examples, in kine with the comment of @maceligueta but i already made my point, so i ll leave it here.

[pooyan-dadvand]

I admit that the core cleaning is a good idea. Moreover, I see for example the #2194 that you mentioned correct a step in this way which was discussed in technical committee and applied by protocol. (and still waiting comments to be approved and merged)

I understand that codes which are used in one application "may" be moved to that application. But any code used by at least two applications should go to the core in order to avoid duplications. Unless we merge those two applications or make on based on the other one. Saying that I would highly appreciate if you can provide a short sample list of files which can be removed or moved to the corresponding application.

I would also like to say that I share @maceligueta opinion about having more important pending changes which affect the performance and efficiency of the core like changing to AMatrix or reducing the Nodeand Dofmemory footprint.

Finally It is normal that in a code every one has some part that knows better and can contribute more but I am against of territory based team working and welcome developer to contribute to different part of the code. Nevertheless changing to the core should be more discussed and find a consensus base on open discussion to provide a common and standard base for all.

[josep-m-carbonell]

Thank you @pooyan-dadvand. Me and other developers could try to make a list for a future re-ordering and cleaning.

[RiccardoRossi]

I believe that this can be closed as inactive. We can reactivate this very same thread as needed or eventually open a new one with the proposals