Integration of DEM application

[jginternational]

For the new release, a decision must be taken about DEM.

• OPTION A: Create a new app Create a single app for the DEM application
• OPTION B: Pack DEM as a single problemtype Deploy this new problemtype with GiD internet retrieve system Add the logo in this interface and launch the new problemtype

In both options, the compiled Kratos should be the same

@KratosMultiphysics/dem @KratosMultiphysics/technical-committee

[maceligueta]

In technical terms, I prefer Option A. However, the team @KratosMultiphysics/dem is fully involved in several projects right now and we lack resources for writing a new GUI. In terms of workforce resources I would choose Option B, as the GUI we are using now is fully operational.

[jginternational]

I rather prefer Option A. I can help you providing a template of a basic application, so you just need to add things to the xmls (elements, conditions...), and giving support for the tree login and the files writting, but unfortunately all the implementations related to the project parameters written in python have been deprecated, they are not longer supported by the common code, so an effort must be done there (reading json instead of writing python).

Option B can be faster to achieve, but keep in mind that will remain as a separated problemtype.

[pooyan-dadvand]

@jginternational How is going with DEM interface?

[jginternational]

@maceligueta If we want to discard the "old" DEM integration and create a new app in the current problemtype, we'll need to define some things, so I'll create a new issue for that

[jginternational]

Alle fine, we have defined a draft for the DEM app. @KratosMultiphysics/dem

Dem app will always be in 3D, Dynamic, and explicit, and will use the Symplectic Euler integration scheme. Only available in OpenMP, with no linear solver.

In the parts section: there is only one element type. To start with, we will force to mesh this volumes with spheres. There will be a materials list and a Constitutive law list

In the boundary conditions section:

• Inlets: surfaces, lines or points : uses intervals
• Velocity and angular velocity: uses intervals

In the conditions section:

• Walls: surfaces (triangles)

Results:

• Elemental (Particles)
• Walls

For the write procs, there will be 4 mdpa files and a projectparameters.py

• mdpa1 (parts)

  • Properties
  • Nodes (only parts -> inefficient)
  • Elements (Spheres, will need to add this format to the accepted - eid pid nid rad)
  • Submodelparts
    • Elements
    • Velocity and angular velocity

• mdpa2 (walls)

  • Properties
  • Nodes (only walls-> inefficient)
  • Conditions
  • Submodelparts
    • Conditions

• mdpa3 (inlet)

  • Properties
  • Nodes (only walls-> inefficient)
  • Submodelparts
    • Inlet nodal conditions

• mdpa4 (clusters)

  • Empty

For the project parameters, check the old writing script. This should be converted to json soon, but thats another issue

[jginternational]

I've reached a dead end road.

Inlet condition has more than 50 parameters, so I can't include them in a window. DEM-FEM-Wall has 24 parameters...

GiD's customlib has an implementation (not documented) of 'Tab' for grouping parameters in big windows. To use this, we'll need to change the common scripts for the kratos applications, maybe change all the kratos applications xmls, and some GiD scripts.

I've tried to split the parameters, apply linear velocity and angular velocity in separated processes but, since DEM is not using the process system, it's not possible to have it splitted in the GUI and joint in the mdpa, unless we access the data element by element or node by node.

Furthermore, if we could pass over this issues, this app should be used for testing and be better than the old one. I don't think that this can be achieved. This app is becoming an hybrid between 2 worlds, it has been created for working in a different way.

My recommendation: Keep this work in a branch, and wait until DEM is upgraded, and create a link to launch the old (current) G-DEM interface for this release

This was done in branch add-DEM-application-link

@maceligueta @KratosMultiphysics/dem @KratosMultiphysics/technical-committee @pooyan-dadvand

[maceligueta]

Just a comment about @jginternational

I've tried to split the parameters, apply linear velocity and angular velocity in separated processes but, since DEM is not using the process system, it's not possible to have it splitted in the GUI and joint in the mdpa, unless we access the data element by element or node by node.

We are using something very similar to a process, but the inputs are both the linear and the angular velocitites (with their intervals). This is actually the problem. In the future we will try to isolate each component of the imposed motion conditions. It will ease the work of the GUI, either with processes or with utilities.

[jginternational]

I close this issue now but I'll open it when the development continues

[jginternational]

@merceln @maceligueta @farrufat-cimne

Write me when the DEM branch is ready to merge Master. We should merge it as soon as possible, even if it has small bugs. Bugs can be fixed but I'll need time to merge the conflicts and be sure that DEM changes to common code does not break anything for the others' applications

[merceln]

@jginternational Ok. We hope to have it almost ready at the end of the day.

[merceln]

@jginternational We are done. Detected bugs:

• Material properties are not written in MDPA files if the groups have not been opened on the problemtype tree at least once

• Error when trying to modify the inlet material on the tree

• The properties id on element connectivities (parts MDPA) is not recognised (always 0)

Could you please help us solve these problems? Especially the last one, which is critical to run a case.

[jginternational]

I've merged the branch. Common bat files modifications were not included due to they were not correct.

You had: export LD_LIBRARY_PATH="$3/kratos":"$3/kratos/libs":$OLD_LD_LIBRARY_PATH The current (and proper): export LD_LIBRARY_PATH="$3/exec/Kratos":"$3/exec/Kratos/libs":$OLD_LD_LIBRARY_PATH Notice the /exec/

About the matplotlib, we need to talk to @roigcarlo

[merceln]

@jginternational @farrufat-cimne @maceligueta What's pending (added an additional point):

• [x] Material properties are not written in MDPA files if the groups have not been opened on the problemtype tree at least once

• [x] Error when trying to modify the inlet material on the tree: invalid command name "" while executing "$domNode getAttribute $attributeName $defaultValue" (procedure "get_domnode_attribute" line 5)

• [x] The properties ID on element connectivities (parts MDPA) is not recognised (always 0)

• [x] Each set of properties should have a unique ID (now, it is initialised in each MDPA, so there are repeated properties IDs)