jgiven100 commented 4 years ago

Add `"material_sets"` to `entity_set.json`

Summary

Adding "material_sets" to the entity_set.json will eventually be used to define multiple material properties for particles from a single particle input file (particles.txt). Using a flag to indicate when to use the "material_sets" listed within the entity_sets.json allows for either manual particle definition or multiple particle generators (current implementation). As a result user will have 2 viable methods for developing a model with more than one material.

Motivation

Including "material_sets" in the entity_set.json will eventually be used to define mutliple materials for particles from a single particle input file (particles.txt).
Currently, "material_id" is defined by the particle generator. If n materials are desired, multiple particle input files (particles_0.txt, ... , particles_n.txt) are necessary.
For some geometries (e.g., axisymmetric), a single particle input file (particles.txt) and location file (particles_cells.txt) is easier to produce although multiple materials are necessary.

Design Detail

The existing format of "particle_sets" will be adopted for "material_sets". The "set" will be defined by particle_id:

{
    "material_sets": [
        {
        "id": 0,
        "set": [p0_0, ... , p0_n]
        },
        {
        "id": 1,
        "set": [p1_0, ... , p1_n]
        }
    ]
}

p0_i is the id of a particle within the set with id 0.

The current method of using a different particle generator for each desired material is convinent if additioanl particles are added since there is no need to regenerate the previsouly determined particle_sets. Additionally, particle sets can be developed automatically by the generator. The benefits of using multiple generators should remain.

Therefore, the eventual implementation of using "material_sets" from the entity_set.json should rely on a flag in the particle generator such as:

"material_id": -1

If -1, the flag will initiate an if-statement at L1785 of mesh.tcc. Within this section of code will be a for-loop moving through all particles:

The material_id will be defined from the entity_set.json instead of the scalar user input
The function create_particles will be called at the end of each loop

Further details of this implementation will covered in a subsequent RFC!

Drawbacks

Data type of material_id must be updated from unsigned to int
mesh.tcc currently does not call the entity_set.json file
Using a loop to define material_id will have increased cost

Rationale and Alternatives

If "material_sets" is added to the entity_set.json, this leads to defining multiple material_id for any given particle input file (particles.txt). Using a flag to achieve this result in current input files remaining usable while offering increased options to the user.

One alternative considered was to define the "set" by the "pset_id" instead of the "particle_id":

{
    "material_sets": [
        {
        "id": 0,
        "set": [ps0_0, ... , p0_n]
        },
        {
        "id": 1,
        "set": [ps1_0, ... , p1_n]
        }
    ]
}

ps0_i is the id of a particle set within the set with id 0.

This was not selected since the particle generator currently defines the same value for pset_id for all particles from any given input file. Thus, if the material_id was defined by the pset_id, the pset_id would additionally need to be updated (i.e., 2 loops instead of 1).

If not implement, users will not have the option to manually define material properties via the particle_id. In some instances where only a few particles are desired to be changed, it would be much quicker to define material through the entity_set.json instead of developing an additional input particle file.

Consider an axisymmetric model with a very large number of elements where failure is initialize through selecting specific elements to weaken. Loading all particles as a single input file and manually selecting the 10 elements to have different material properties is much quicker than developing 2 input files. If the model is split into 2 seperate input files, it is perhaps no longer axisymmetric and thus requires more pre-processing. Additionally, creating the the particle_cells file becomes more difficult as more input files are used.

Prior Art

The "material_id": -1 flag is taken from the current cset implementation on L482 of mesh.tcc.

Unresolved questions

More details regarding the eventual implementation of using "material_sets" from the entity_set.json to define material_id will be in a future RFC. Reading comments about expanding the information included in the entity_set.json file seems like a necessary first step.

Changelog

bodhinandach commented 4 years ago

Hi @jgiven100 , some comments from my side:

Currently, "material_id" is defined by the particle generator. If n materials are desired, multiple particle input files (particles_0.txt, ... , particles_n.txt) are necessary.

If this is the concern, couldn't we just use the particle_sets in entity_set.json instead of creating a new material_set. There, you can use just one particles.txt file to put all of them together? I am not sure the pset_id in mpm.json is linked with pset_id in entity_set.json, but linking them does not require a big change.

If -1, the flag will initiate an if-statement at L1785 of mesh.tcc. Within this section of code will be a for-loop moving through all particles:

The material_id will be defined from the entity_set.json instead of the scalar user input

The function create_particles will be called at the end of each loop

What is the motivation for this? Do you plan to change the material model for certain particles at a certain time step?

A further concern that I might have is whether this provides easy handling of a material point with two different material models, i.e. two-phase particles. It is in my TODO list of refactoring that part too.

jgiven100 commented 4 years ago

Thanks for the feedback @bodhinandach

Currently, "material_id" is defined by the particle generator. If n materials are desired, multiple particle input files (particles_0.txt, ... , particles_n.txt) are necessary.

If this is the concern, couldn't we just use the particle_sets in entity_set.json instead of creating a new material_set. There, you can use just one particles.txt file to put all of them together? I am not sure the pset_id in mpm.json is linked with pset_id in entity_set.json, but linking them does not require a big change.

I think that using the particle_sets in entity_set.json might require an extra step:

In particle_sets we define the id and set
The relationship between pset_id and the material_id must be defined to link the material_id and the set of particles

vs.

In material_sets, we define the id and set; the material_id is already linked with the set of particles

Since the set of particles must be manually defined within entity_set.json for either of the above methods, it saves a step to immediately link the set of particles to the material_id in entity_sets.json.

If -1, the flag will initiate an if-statement at L1785 of mesh.tcc. Within this section of code will be a for-loop moving through all particles:

The material_id will be defined from the entity_set.json instead of the scalar user input

The function create_particles will be called at the end of each loop

What is the motivation for this? Do you plan to change the material model for certain particles at a certain time step?

In L1787 of mesh.tcc, the create_particles function is called where material_id is expected to be scalar. Since multiple material_id will be associated with the particles from a single particle.txt, I was proposing to call create_particles for each coordinate within particle.txt through a loop. This loop would be terminated once sending the final coordinates from the particle.txt to the create_particles function. This portion of mesh.tcc is not associated with timesteps. (I'm not sure I answered/fully addressed your comment with my response).

A further concern that I might have is whether this provides easy handling of a material point with two different material models, i.e. two-phase particles. It is in my TODO list of refactoring that part too.

This is a good thing to note. I'm not sure I understand the two-phase particles well enough to appreciate how this feature could be a negative impact.

ezrayst commented 4 years ago

Just to add, this is in response to this discourse discussion.

kks32 commented 4 years ago

Thanks @jgiven100

While particle, nodes and cell sets are subsets of each class, material_sets is not.

Why not just define material_sets in the input file and define the relevant particle sets in the entity-sets.json file

    "material_sets": [
        {
        "mid": 0,
        "pset_id": 0
        },
        {
        "mid": 1,
        "pset_id": 1
        }
    ]

This will overwrite any materials previously set. This will be an optional argument, so it won't affect older files.

Yes, you have to define particle sets separately.

ezrayst commented 4 years ago

@kks32, I see. Thanks for the input. So we will have a two-step process then: particles will be initialized and created first through generator and then the material_id will be updated depending on the optional argument. Do I understand this correctly?

jgiven100 commented 4 years ago

Thanks for the feedback @kks32

Why not just define material_sets in the input file and define the relevant particle sets in the entity-sets.json

This makes sense to me.

While I had been planning to redefine material_id within mesh.tcc, it seems I should update in mpm_base.tcc after particle sets are defined based on entity_sets.json

kks32 commented 4 years ago

@jgiven100 yes, implementation in mpm_base.tcc sounds good. You wouldn't need to change anything in mesh. Would you like to create a draft PR from your repo, and we can discuss as we go along? Thanks!

bodhinandach commented 4 years ago

I am closing this as PR #674 has been merged.

cb-geo / mpm