Kratos Barcelona Meeting Minutes 2019-1-17

[maceligueta]

Minutes of the meeting of the Kratos Barcelona Group. 17th January 2019

_List of attendants: Pooyan Dadvand, Carlos Roig, Riccardo Rossi, Miguel Angel Celigueta, Rubén Zorrilla, Vicente Mataix, Marcelo Raschi, Josep Maria Carbonell, Alejandro Cornejo, Deniz Cagri, Fernando Rastellini, Pablo Becker, Daniel Diez, Riccardo Tosi, Marc Núñez, Nicola Germano, Jordi Rubio, Lucia Barbu, Sergio Jiménez, Stefano Zaghi_

1- Kratos Workshop

It's held on 25-29 March, in München. Contact @jcotela or Roland Wüchner for questions.
@pooyan-dadvand explains the general agenda for the workshop, and recommends attendance. It's very useful for knowing all the developers in person, as well as companies using or interesed in using Kratos.
Altair attendees confirm Altair sponshorship. Other companies might sponsor as well.

• First day of Workshop: dissemination, interaction with companies, short presentations by Kratos developers and by the companies.
• Second day: round table. Themes to be decided.
  Please answer in this issue to propose topics to be discussed during this second day!
• Third day: Kratos courses.
  Mataix asks about registration protocol: not ready yet.
  Limit of the room: 40 people.

2- Release 6.1

Initially planned for November 2018. Delayed. Kratos Workshop is an implicit deadline, so the master branch will be frozen on 15th February. No objections (people are asked but nobody considers this date impossible in Barcelona).
Mataix proposes 7.0 as Release number, because it includes Pybind and AMatrix. Big consensus about it. If any inconvenient, please state in this issue.
Portability to Amatrix should indeed be included in this release. Otherwise, no point in changing 6.1 to 7.0.
FluidDynamics and DEM are already working with AMatrix. The rest should make an effort to try the compatibility ASAP!
This release must contain a FEATURE LIST and a WHAT’S NEW. This is very important.
@jrubiogonzalez says that the new features should be accompanied by instructions that state how to use them (json, mdpa).

3- The Committees

The new committees are commented, as a reminder of the issue posted to the Kratos Community.
Those committees are for:

• Input/Output (4 members)
• Implementation (5 members)
• Design (3 members)
  Total consensus is expected for the recommendations posted by the Committees. Otherwise, the disagreement must be posted (with the diverse opinions).
  @maceligueta asks when is the election for the @KratosMultiphysics/technical-committee. Apparently, the second year is about to finish. After the workshop, when people will know each other better, is a good moment for the election.

4- Apps as Python modules (more pythonic)

The new style for importing the applications and their scripts is described.
Look at:
https://github.com/KratosMultiphysics/Kratos/wiki/Applications-as-python-modules
Or for example:

3820 #3822

@loumalouomega says that this approach allows organization of python scripts in subfolders.

Questions & Comments

@frastellini :
He shows the SWOT tables he has received from developers. Some are missing. He explains the good points of making this table and clarifies that 'Weakness' depends on the developers while 'Threat' depends on externals.
Conclusions will be extracted when more SWOT tables are received.
Rastellini proposes COMPOSITES as a subject for the second day of th Workshop

@loumalouomega :
He claims that a lot of Documentation is missing, specially for beginners. It's almost impossible to start working with Kratos by yourself.
@jrubiogonzalez supports the comment from Altair.
@loumalouomega names Doxygen, but many attendees doubt about usefulness of Doxygen when entering the Kratos world.
@marandra defends tutorials.
Several comments in the direction of 'The industry needs a nice portal to get into Kratos'.
From the industry, @zaghistefano ’s opinion is that GiD is a bottleneck for Kratos right now.
@RiccardoRossi asks for volunteers for updating the wiki, so it's easier to navigate.
@roigcarlo and @rubenzorrilla will try to re-write some parts of the current wiki.

@josep-m-carbonell :

• When using linear solvers, no alternative Space for sparse matrices can be used in practice. This is due to some hardcoded 'UblasSpace', and some work is required to generalize this.
  @pooyan-dadvand requests a PR from @josep-m-carbonell
  @josep-m-carbonell answers that anyone else can do it as well.
• The nlohmann json has introduced errors. @loumalouomega says that the error commented can be fixed easily.

@roigcarlo :
He reminds that the new CI is ongoing work. It’s actually working, but in testing stage already.

@rubenzorrilla :
When can we remove the really old applications?
@RiccardoRossi says that some were deleted already, some others will be finally accepted for deletion during the Workshop. @maceligueta says that we should update the list of deprecated applications.

[loumalouomega]

@maceligueta, the error was already fixed for JSON

[philbucher]

Thanks @maceligueta for documenting!

[pooyan-dadvand]

@KratosMultiphysics/all: it would be great to give some discussion theme for the workshop here ASAP.

[maceligueta]

Discussion topic: Couplings: code desing.

[rubenzorrilla]

Discussion topics:

• How to use the embedded capabilities (construct an embedded coupled solver)
• How to use the anisotropic re-meshing and other MMG capabilities (@loumalouomega what do you think?)

[loumalouomega]

Discussion topics:

* How to use the embedded capabilities (construct an embedded coupled solver)

* How to use the anisotropic re-meshing and other MMG capabilities (@loumalouomega what do you think?)

In fact I suggested that to @jcotela in the inscription form that I filled yesterday

[jcotela]

More topics:

• Maintenance of large applications: how to balance development of new features with ensuring the quality of what is already there. Should we go for a "core application"+sandbox/development derived applications?

[pooyan-dadvand]

Topics:

• MPI Core: Mostly a technical discussion about its interface and roadmap
• Errors, warnings and other Logs formats: Translation, uniformity, ...
• Regression tests: How to add them as the final stage in nightly/weekly builds.

[antonialarese]

Topics:

• Definition (and publication) of quality standards and requirements for applications (aside the core applications, there should be some other "categories" to classify the level of maturity of each technology. For each of them minimum requirements should be defined)

[loumalouomega]

Topics:

* Definition (and publication) of quality standards and requirements for applications (aside the core applications, there should be some other "categories" to classify the level of maturity of each technology. For each of them minimum requirements should be defined)

I will even add to discuss what an app is, what is supposed to contain, etc... Recently some people are thinking in apps as something where I can do anything, and we should think in some standard definitions.

[philbucher]

answering to @antonialarese : I would say an app should fulfill at least the following standards:

• Using as much from the Core as possible (e.g. processes, testing-environment)
• Using the AnalysisStage and the PythonSolver (if applicable)
• Tests !!!!!
• follow the Style-Guide (and also other conventions)
• (At least a small) ReadMe abt the Application / what the application does

[RiccardoRossi]

I would propose as discussion point:
- shall we prepare for shared-memory parallelism beyond openmp?

[RiccardoRossi]

I would propose as discussion point:
- shall we prepare for shared-memory parallelism beyond openmp?
- sandbox vs core applications

[philbucher]

+1 for the suggestion of @maceligueta abt the general coupling of applications

also I think it would be good to discuss what to do with old/outdated applications. Should we remove them at some point if none is maintaining them for years?

[jcotela]

Discusion proposal:

• Design of a common interface for printing output in different formats (gid, vtk, h5, probes, sensors, cuts...). Is an Output class (similar to Process) needed?

[philbucher]

Discusion proposal:

* Design of a common interface for printing output in different formats (gid, vtk, h5, probes, sensors, cuts...). Is an `Output` class (similar to `Process`) needed?

I believe so, this is already discussed in #3766