Multi-material management

[atpellet]

I understand Matter only support single-materials for now. Since I need it, I would like to implement multi-material handling.

My first need would be to store de particle-mass, in... the particles. Is there a specific reason why it was implemented in Simulation() and not Particles() ? In other words, might there be major issues changing it ?

Also, if I implement these modifications, would you be interested in pulling them to the source code ?

[larsblatny]

Hey @JoWsky,
This is a very good point you are raising.

The reason for not including multi-material support was to keep the code simple and efficient. With different materials, one would need to (worst case) make all (or at least some) material "constants" into arrays of length Np. If you have a specific case you could, e.g., say particle indices 1-100 have these sets of constants and particle indices 100-200 have another set of constants. If you can find a good and general way of doing this that does not effect the computational efficiency significantly, I'd be very interested in having this as a PR to master.

Regarding the mass, do you really need to make this a material property? Let's assume you have two materials "colliding", one material with larger mp than the other. Once the masses are interpolated to the grid, you will get an area between your two materials where these masses will be "averaged out". Depending on your problem, this may not be desirable...

[larsblatny]

Nice @JoWsky ! Would definitely be interested in seeing your implementation!

[atpellet]

Hi @larsblatny,

I've implemented my modifications in the "multimaterial" branch. You can check it if you want. I don't know what I did differently this time, but it seems this solution might not be sensibly slower than the original, as I thought before. I will get back to you on this subject and make the PR. If my modifications don't make the code slower, it might be easier and cleaner to implement it by default and not just as an option...

Basically, the MULTIMATERIAL option is defined (or not) in tool.hpp, as for THREEDIM. Accordingly, #ifdef MULTIMATERIAL, the particle_mass definition in Simulation() class is removed and replaced by "mass" in Particles() class. Then all changes in g2p, musl, are made.
I'd like to point out that with this solution, particles.mass needs to be defined in the main function in mpm.cpp as well as the wave_speed and dt_max.

Cheers,

AP

[atpellet]

@larsblatny
I confirm now that my implementation is, according to very basic comparison, as fast if not faster than the original v1.0.

You can check the multimaterial branch to judge for yourself, with my test set up in "tests/MULTIMATERIAL_TEST/". I think would be cleaner and easier to implement MULTIMATERIAL directly in the code instead of an option. Let me know what you prefer and I'll make the PR.

[larsblatny]

Thanks a lot for sharing your code @JoWsky !
I will have a look soon. I'm under a deadline so this is the reason for my slow response. Will get back to you soon :)
Lars

[larsblatny]

I've looked through the code now, great work! Very interesting to see that you do not measure any reduced computing time. This means that we are not yet memory-bound. While we could create a PR and merge with master, I think we should consider what this means for the future development:

• Should we add std vectors for every particle quantity, not just mass? That includes mass, Young's modulus, Poisson's ratio and every plastic quantity (which could be up to 5 depending on plastic model). What is the computer memory needed to sustain such an option without affecting performance?

• Or is it better to consider one vector over particle class instantiations?

The latter was initially considered, but decided against due to how it would effect the loops in P2G, G2P, EulerStep etc... as you then would have to load in all the particle data when you'd really just need to loop over velocity. But it could be that this should be reconsidered and checked for performance if we'd really want a multimaterial-based code.

In the meantime, feel free to work on this new branch and/or make your fork available to others. I'm quite sure that this will be very useful to others who might want just one or two material constants transferred into particle quantities.