Altair RISE

A program to recognize and reward our most engaged community members

Nominate Yourself Now!

Error: Nullptr silent crash plugin

Hi all!

I am currently working on my own liquid bridge model. Now, as inspiration I am using the CLiquidBridgeModel.cpp that was provided here in the discussions as API Example.

This CLiquidBridgeModel uses custom properties m_BridgeStatus, m_BridgestatusDelta as well as m_BridgeForceDelta and m_BridgeForce.

I have tried implementing this as well but my plugin results in EDEM silently crashing immediately after start of the simulation (first loop). Whenever I try to debug in MSVS I can see where it goes wrong. I have added a safeguard to make sure that the code exits calculateforce() early if there is no liquid bridge yet present and if we are not within the distance that a bridge should form (to safe computational load due to larger contact radius). When this if statement is excecuted it tries to use the BridgeStatus which is a nullptr. This results in the following error:

I don't understand what I am doing wrong in my script and why it is different from what is done in CLiquidBridgeModel.cpp. Why does the bridgeStatus getvalue not work correctly?

My code is added in the .xtx file. I would appreciate if anyone has any idea on how to fix this. I am using EDEM 2025

Thanks!

Kind regards,

Jan-Thijn Wijnker

CVariableCohesionV2.txt

Find more posts tagged with

EDEM

Errors

Accepted answers

Stephen Cole

Hi Jan-Thijn,

I think i see the issue. The original calculate force function is:

calculateForce(int threadID,

		const NCalcForceTypesV3_8_0::STimeStepData& timeStepData,

		const NCalcForceTypesV3_8_0::SDiscreteElement& element1,

		NApiCore::ICustomPropertyDataApi_1_0* elem1CustomProperties,

		const NCalcForceTypesV3_8_0::SDiscreteElement& element2,

		NApiCore::ICustomPropertyDataApi_1_0* elem2CustomProperties,
		NApiCore::ICustomPropertyDataApi_1_0* contactCustomProperties,

		NApiCore::ICustomPropertyDataApi_1_0* simulationCustomProperties,

		const NCalcForceTypesV3_8_0::SInteraction& interaction,

		const NCalcForceTypesV3_8_0::SContact& contact,

		NApiHelpersV3_8_0::CSimple3DVector& tangentialPhysicalOverlap,

		NCalcForceTypesV3_8_0::SContactResult& contactResults

I've higlighted contactCustom property position. For yours you have:

calculateForce(

int,

const NCalcForceTypesV3_8_0::STimeStepData&,

const NCalcForceTypesV3_8_0::SDiscreteElement& e1,

ICustomPropertyDataApi_1_0* cp1,

const NCalcForceTypesV3_8_0::SDiscreteElement& e2,

ICustomPropertyDataApi_1_0* cp2,
ICustomPropertyDataApi_1_0*,

ICustomPropertyDataApi_1_0* contactCP,

const NCalcForceTypesV3_8_0::SInteraction&,

const NCalcForceTypesV3_8_0::SContact& contact,

CSimple3DVector&,

NCalcForceTypesV3_8_0::SContactResult& result)

You can see contactCP looks out of place. It's been set as a simulationCustomProperty not a contact property.

Regards

Stephen

Stephen Cole

Hi Jan-Thijn,

I had a check with a 10 mm radius particle that has a 12 mm contact radius. This is just using the built-in Hertz model but we can see there is a contact detected before the physical contact.

I don't know if there is something else happening in this case, but I expect the particles to contact the geometry before physical contact occurs, and that this is passed to the API.

Regards

Stephen

All comments

JT_Wijnker_11

Hi all,

Following up on my earlier post about my custom liquid bridge plugin, I’ve made some progress narrowing down the issue, but I still need help confirming a key point.

To recap, I’m developing a liquid bridge model inspired by CLiquidBridgeModel.cpp. Like that example, my model uses custom contact properties: BridgeStatus, BridgeForce, and their respective deltas. However, unlike the example, my plugin causes EDEM to silently crash at the very start of the simulation. Debugging in Visual Studio shows that the crash occurs when trying to access BridgeStatus, which is returning a Nullptr.

In my model, each particle has a molten shell that forms as it shrinks, based on the difference between its initial and current radius. I want liquid bridges to form when the molten layers of two particles interact, which means before the solid cores come into physical contact. This interaction may happen even at a small positive surface-to-surface distance.

Originally, I assumed the issue was due to EDEM not having created a contact yet, and therefore not allocating the custom contact properties. However, I am using a sufficiently large Contact Radius, which should allow contact entries to be created before actual overlap. According to the documentation, this should trigger contact creation, and since my calculateforce() function is in fact being called, it seems like a contact does exist.

So now I am trying to confirm the following. If calculateforce() is triggered because the Contact Radius is large enough, is it still possible for contactCP->getValue("BridgeStatus") to return nullptr? Or should the custom contact property always be allocated by that point?

I have verified the following

The property names are consistent and correctly registered
The simulation has progressed through multiple timesteps
calculateforce() is being called
Despite this, BridgeStatus still returns nullptr when accessed

Is there any case where EDEM creates a contact but delays allocating the contact properties? Or is there something else I might be overlooking that would cause getValue() to fail even after a contact is detected?

Any guidance or suggestions would be greatly appreciated

ThanksJan-Thijn Wijnker

Stephen Cole

Hi Jan-Thijn,

The custom properties for contacts only exist when there is a contact…but you can only ever access them when there is a contact so this shouldn't be an issue.

I suspect the problem is in the definition of hte custom properties.

Check getDetailsForProperty . Is hte property you want to write to setup correctly. Not an issue in your case but if you set it up with 1 element and then try to write to element 2 or 3 (i.e. force components) then it would crash due to memory error
Check getNumberOfRequiredProperties . Have you added a new contact property but not increased the number of contact properties registered?
Under the starting function have you registered contact properties? If copying code it can be common to setup a contact property as a particle or simulation property, accessing it would then cause a memory error

Regards

Stephen

JT_Wijnker_11

Hi Stephen,

Thank you for your reply. I have checked your comments and as far as I know I have done this corectly. But lets go over it in a bit more detail.

1. getDetailsForProperty:

Number of elements is 1 for both cases and in my code I try to acces them by:
const double* bridgeStatus = contactCP->getValue(BRIDGE_STATUS.c_str());
double* bridgeStatusDelta = contactCP->getDelta(BRIDGE_STATUS.c_str());

2. getNumberOfRequiredProperties

I am pretty sure his is the correct way of telling the solver we have 2 custom contact properties.

3. Starting function: I do not register any contact properties inside starting(). My starting function only accesses my GUI to set wetting angles for geometry and particle types. Is that the problem?

Also, in my setup I declare the use of custom properties

But still, the following code results in a nullptr (same problem for BridgeForce)

Please correct me if I am wrong and if I am overlooking something subtle.

Kind regards,

Jan-Thijn Wijnker

Stephen Cole

Hi Jan-Thijn,

I think i see the issue. The original calculate force function is:

calculateForce(int threadID,

		const NCalcForceTypesV3_8_0::STimeStepData& timeStepData,

		const NCalcForceTypesV3_8_0::SDiscreteElement& element1,

		NApiCore::ICustomPropertyDataApi_1_0* elem1CustomProperties,

		const NCalcForceTypesV3_8_0::SDiscreteElement& element2,

		NApiCore::ICustomPropertyDataApi_1_0* elem2CustomProperties,
		NApiCore::ICustomPropertyDataApi_1_0* contactCustomProperties,

		NApiCore::ICustomPropertyDataApi_1_0* simulationCustomProperties,

		const NCalcForceTypesV3_8_0::SInteraction& interaction,

		const NCalcForceTypesV3_8_0::SContact& contact,

		NApiHelpersV3_8_0::CSimple3DVector& tangentialPhysicalOverlap,

		NCalcForceTypesV3_8_0::SContactResult& contactResults

I've higlighted contactCustom property position. For yours you have:

calculateForce(

int,

const NCalcForceTypesV3_8_0::STimeStepData&,

const NCalcForceTypesV3_8_0::SDiscreteElement& e1,

ICustomPropertyDataApi_1_0* cp1,

const NCalcForceTypesV3_8_0::SDiscreteElement& e2,

ICustomPropertyDataApi_1_0* cp2,
ICustomPropertyDataApi_1_0*,

ICustomPropertyDataApi_1_0* contactCP,

const NCalcForceTypesV3_8_0::SInteraction&,

const NCalcForceTypesV3_8_0::SContact& contact,

CSimple3DVector&,

NCalcForceTypesV3_8_0::SContactResult& result)

You can see contactCP looks out of place. It's been set as a simulationCustomProperty not a contact property.

Regards

Stephen

JT_Wijnker_11

Hi Stephen,

Jeesh, what an oversight from my part…. Thanks for the help. You really helped me get back on track again.

Kind regerds,

Jan-Thijn Wijnker

JT_Wijnker_11

Hi Stephen,

A short question. I use an enlarged contact radius for the particles in my script. Now this results in the particle-particle contact to be registered even when there is no physical overlap. Now I expected the same to happen between particle and geometries. However, in my script, even when using larger contact radii for particles then their physical one, particle-geometry contacts are only registered with physical overlap.

I was wondering if this is really true and contact at a distance is only supported for particle-particle interactions and not for particle-geometry interactions. However, preservePGContact does exist. So therefore my confusion on why this would not be supported.

Thanks

Jan-Thijn Wijnker

Stephen Cole

Hi Jan-Thijn,

I had a check with a 10 mm radius particle that has a 12 mm contact radius. This is just using the built-in Hertz model but we can see there is a contact detected before the physical contact.

I don't know if there is something else happening in this case, but I expect the particles to contact the geometry before physical contact occurs, and that this is passed to the API.

Regards

Stephen