How can I prevent unwanted bonds between separately generated stems when using Bonding V2 in the EDE

Question

Hello everyone,

I am currently developing an API-based stem generation workflow in Altair EDEM and I am using Bonding V2 to create bonded stems (meta-particle-like chains made of segments and knots).

My stems are generated programmatically during the simulation using a factory-style approach. Each stem consists of multiple particles that should only bond with their direct neighbors inside the same stem. Each particle stores metadata such as:

* StemID
* StemElementIndex

The issue is the following:

If multiple new stems are generated within the same timestep (or the same bond-creation window), unwanted bonds can appear between particles belonging to different stems, because they are spatially close and share the same bonding time conditions.

What I would ideally like to achieve is:

* Allow bonds only between particles that belong to the same stem
* Prevent bonds between particles from different stems
* If prevention is not possible, detect and remove such unwanted bonds after creation

From the API/documentation I have found access to contact models, custom properties, and contact handling, but I have not yet found a clear way to directly inspect or delete already created bonds.

My questions are:

* Is there any API-supported way to inspect, break, or delete existing bonds created by Bonding V2?
* Is there a recommended way to prevent unwanted inter-stem bonds when generating multiple bonded structures during the same timestep?
* Would a custom contact model plugin be able to prevent Bonding V2 from creating bonds between particles with different StemIDs?
* Is there any best practice for this kind of workflow when creating bonded multi-particle structures through the API?

At the moment I am considering a purely preventive strategy, for example:

* generating only one new stem per bonding timestep
* enforcing a larger minimum spacing between newly generated stems
* blocking neighboring spawn cells in the same timestep

But I would like to know whether EDEM provides a cleaner or more direct solution since I might need the possibility to remove bonds in later situations again.

Any advice, best practices, or pointers to the correct API classes would be very helpful.

Thank you very much.

Stephen Cole · Answer

Hi,

It should be possible to keep the in-built Bonding model, as you say it maybe best not to make any modificaitons to this.

The Contact Models in EDEM work as a chain.  The factories (includding API factoris) run first and then once the particles are generated for this time-step the Contact Models run, starting with the first model in the chain.  This first model would typically be the bonding v2 model and then once this has run the second model, typically Hertz-Mindlin, runs and adds additional forces to the bond forces already calculated.

You can create any number of 'additional' contact models and place them in the chain. So in your case we can place a custom Contact Model right after the bonding V2 model.

The new model would have to have the 'Bond Status' custom property.  This custom property should be the same as the previously shared API code:

const string CBonded::BOND_STATUS = "BondStatus";

if (0 == propertyIndex &&

    eContact == category)

{

    strncpy(name, BOND_STATUS.c_str(), NApi::CUSTOM_PROP_MAX_NAME_LENGTH);

    dataType         = eDouble;

    numberOfElements = 1;

    unitType         = eNone;

return true;

}

Note the propertyIndex doesn't have to be same, just the name, units, number of elements and data type.

You could also add your local particle ID property.

Once you have this you could check if the local particle ID is different, and that the bond status is 1 (status 1 = bond created), in which case you could set bond status to 0.  To set bond status to 0 you could use the config for time-step feature or set a Bond status delta to -1.

This process should work OK with the existing codes, it may require a single stem test case to make sure the logic and timing of changing the elements all matches up, but I believe it should work as described above.

Regards

Stephen

Nadrilon · Answer

Hi Stephen,

thank you very much for the fast and detailed reply.

Yes, I am currently using a custom API factory to generate the stems continuously during the simulation.

Each stem is created as a chain of individual particles (segments and knots), and I am already assigning custom particle properties during creation, including:

* creation time
* a local particle ID
* StemID
* StemElementType
* StemElementIndex
* MetaGroupID

So from the factory side, I do have the information available that identifies which particles belong to the same stem.

My main goal is to keep the project as close as possible to the built-in Bonding V2 workflow, because the project is intended to be carried through with Bonding V2. At the same time, I need a way to ensure that bonds are only created within one stem and not between particles from different stems that happen to be created in the same bonding time window.

From your explanation, I understand that modifying the bonded particle model and checking the custom stem ID at the point of bond creation would be the cleanest solution.

My question is therefore the following:

Is there any supported way to keep using the built-in Bonding V2 model, while adding some custom logic before or after it, for example through an additional chained contact model, so that bond creation can be restricted based on custom particle properties such as StemID?

More specifically, I would like to know whether one of the following is possible:

* Keep the built-in Bonding V2 model, and use an additional custom contact model before or after it in the chain to prevent inter-stem bond creation.
* Use a modified Bonding V2-based model that is as close as possible to the built-in Bonding V2 model, with the only intended change being an additional check using custom particle properties.
* Restrict bond creation not only by matching StemID, but ideally also by checking whether the two particles are direct neighbors in the stem (for example based on StemElementIndex).

The reason I ask is that I would strongly prefer not to replace the Bonding V2 behavior more than necessary. If there is a Bonding V2-derived custom model where the only change is adding this custom-property-based bond eligibility check, that would likely be the ideal solution for my use case.

Would you recommend starting from BondedParticle_CM_v3_1_0 or BondedParticleCustom_3_5_0 for this kind of modification, if the goal is to stay as close as possible to the built-in Bonding V2 behavior?

Thank you again for your help.

Best regards

Stephen Cole · Answer

Hi,

The three points you mention as a preventative strategy are commonly used as a workaround.

The main issue here is that there isn't a 'meta particle' element in the software, so EDEM doesn't know if two contacting elements are part of the same stem or different stems.

Just to confirm you are using the API factory currently?  When using a custom factory you can assign a unique ID to each stem when you create it, this would be best done via a Custom Particle Property.  This would be similar to how the current time is assigned to the particle as a property.

If each stem then has a unique ID you can then modify the bonded particle model. We have an example of code for the bonding model here:

https://community.altair.com/discussion/35365/edem-api-contact-model-example-updated-bond-model-example-of-customisation-of-bond-model

In the code (Cbonded.cpp for CPU) bonds are formed via:

/************************************************************************/

/* Making / obtaining bonds from records                                */

/************************************************************************/

//only particle-particle

if (true == element2.isSphere)

{

    //create bonds if:

    if (timeStepData.time > m_requestedBondTime)

    {

        if (timeStepData.time <= (m_requestedBondTime + timeStepData.timeStep))

        {

            if (m_BondStatus[0] == 0.0)

            {

//change bond status to set that it exists

                m_BondStatusDelta[0] += 1.0;

//this is only recorded once, can later be used to check if bond is in compression or tension

double* m_BondRandDelta = contactCustomProperties->getDelta(iBOND_RANDOM_COEF);

double random_number = rand() % 101; //creates random number between 0 and 100

                random_number = (random_number - 50) / 50; //number between -1 and 1

m_BondRandDelta[0] = random_number;

tangentialPhysicalOverlap = CSimple3DVector();

}

        }

}

}

There are 3 criteria set. First it checks if the current time is greater than the bond request time.  And then the second check is if the time is less than or equal to the current time+timestep.

This means that hte bonds will always be created just after the requested time.  If simulation time-step is 1e-6 s and you request bonds to be created at 1 s the bonds in this case would be created at the 1+1e-6s time point.

The third criteria if (m_BondStatus[0] == 0.0) checks if there are no current bonds (bond status is zero).  If each element had a custom ID for the stem, then at this point you could add code to check if the custom ID of element 1 and element 2 is equal.

Regards

Stephen