I have been trying to use the aggregate_mass function through the expression builder to get what I need, but aggregate_mass return values do not change when the mass properties are changed through design variables (with arrays and DVs). I have tried parameterizing in Arrays as well as in Design Variables and both do not update when design variables alter mass properties. I have tried making computed measures as well, and those do update when design variables alter mass properties, but upon loading an exported .cmd file, it gives the error that the component of mass properties necessary in the aggregate_mass function "is not a valid parameter". Screenshot attached. So that's also not an option for batch mode unless I can get it to work somehow. These measures work well within a single session of ADAMS View, but when loaded give an error and zero out the measure. Is there a way to update these values when I run in batch mode? Currently the only way to update the values that I've seen is to go back into the parameterized expression, hit "Evaluate", and click "ok" back down out of the tree. Available resources also constrain me to using Requests (.res files) as the sole output from my batches. Thank you for any help. Attached Files (1)

How can I obtain aggregate mass properties relative to a particular marker in batch mode with only Requests as outputs?

I have been trying to use the aggregate_mass function through the expression builder to get what I need, but aggregate_mass return values do not change when the mass properties are changed through design variables (with arrays and DVs).

I have tried parameterizing in Arrays as well as in Design Variables and both do not update when design variables alter mass properties.
I have tried making computed measures as well, and those do update when design variables alter mass properties, but upon loading an exported .cmd file, it gives the error that the component of mass properties necessary in the aggregate_mass function "is not a valid parameter". Screenshot attached. So that's also not an option for batch mode unless I can get it to work somehow. These measures work well within a single session of ADAMS View, but when loaded give an error and zero out the measure.

Is there a way to update these values when I run in batch mode? Currently the only way to update the values that I've seen is to go back into the parameterized expression, hit "Evaluate", and click "ok" back down out of the tree. Available resources also constrain me to using Requests (.res files) as the sole output from my batches.

Thank you for any help.

Attached Files (1)

Parents

0 Martin Kieltsch over 4 years ago

If you need something that works during an analysis:

Check out the utility BODY_MASS_PROPERTY that can be used from a user written REQSUB.

The other possibility is an analytical formula using the sum of masses and their locations to determine the total COG.

This involves a tricky macro to loop over all parts above a significant mass and stitch together the expressions as strings.

I'm using both methods as a kind of runtime AGGREGATE_MASS and both show equal results.

But your initial intention rings a bell for a possible bug in the AGGREGATE_MASS() design time function.

Currently I have a user who insists having a model that doesn't react to switching load variants (i.e. switching should create a new full vehicle weight, but dependent parameter stays at the same value) .

In our case there was a real variable created with real_value = (AGGREGATE_MASS(model,model.ground.origo,"mass"))

The method you are using should have perfectly worked, i.e. parametrize a part mass to a design variable should have changed the AGGREGATE_MASS output.

In our case writing out an adm from the changed state, truggered an update, i.e. the adm contained the right mass values. You may check that for your case, too.

If it is the same "update" problem, I'd strongly vote for MSC opening a case on this issue and fixing it !
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Martin Kieltsch over 4 years ago

If you need something that works during an analysis:

Check out the utility BODY_MASS_PROPERTY that can be used from a user written REQSUB.

The other possibility is an analytical formula using the sum of masses and their locations to determine the total COG.

This involves a tricky macro to loop over all parts above a significant mass and stitch together the expressions as strings.

I'm using both methods as a kind of runtime AGGREGATE_MASS and both show equal results.

But your initial intention rings a bell for a possible bug in the AGGREGATE_MASS() design time function.

Currently I have a user who insists having a model that doesn't react to switching load variants (i.e. switching should create a new full vehicle weight, but dependent parameter stays at the same value) .

In our case there was a real variable created with real_value = (AGGREGATE_MASS(model,model.ground.origo,"mass"))

The method you are using should have perfectly worked, i.e. parametrize a part mass to a design variable should have changed the AGGREGATE_MASS output.

In our case writing out an adm from the changed state, truggered an update, i.e. the adm contained the right mass values. You may check that for your case, too.

If it is the same "update" problem, I'd strongly vote for MSC opening a case on this issue and fixing it !
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

No Data