Inconsistent handling of component mass in an asm. Is this a bug?

[RandyJones]

I have a case open at PTC showing inconsistent assembly handling of component mass. See article CS396826.

The problem occurs for a component with no solid geometry and an assigned mass of some value and with 0 for the assigned volume.

I have attached models.7z with a sample assembly (asmtest.asm) with 2 components:

• assigned-mass.prt
  • model with no solid geom and an assigned mass of 5.0
• real-mass.prt
  • model with actual geom and mass calculated the "normal" way
• These models have been created with Creo Parametric 6.0
• You will need to set config.pro option mass_property_calculate automatic

If this is the only component in the asm then it's assigned mass is not used by the asm. Screenshot (Creo Parametric 10.0.1.0) showing the asm mass of 0 when real-mass.prt is suppressed and note the asm has 0.0 even though assigned-mass.prt is showing 5.0.

After resuming the real-mass.prt the asm mass now correctly has 7.2664 which is including the mass of the assigned-mass.prt:

So we have shown the asm level mass has inconsistent behavior. I have tried Creo Parametric releases 6.0 thru 10.0 and all have this issue - have not tried any earlier releases. I want to hear your opinions on "Is this a bug or not?"

[tbraxton]

Have you run a report using this config option to verify that Creo is handling the component with assigned mass when getting the "wrong" result?

Set the configuration option mp_calc_level to all_models to include the summary of assembly components, details of assembly components, and the summary of bodies in the assembly mass property report, and the summary and details of bodies in the part mass property report.

[RandyJones]

Running a mass properties report shows the same inconsistent values for mass.

Setting mp_calc_level to all_models makes no difference - still shows the same inconsistent values for mass. As shown in POR_MP_MASS and in the mass properties report.

[tbraxton]

Using Creo 7.0.9 I get these results using your test models. It appears that something is not right with the way this works (unless PTC has documented why this is happening). I saw nothing in the help files that explains why these results are not as expected. 

I suspect it is working to PTC specification due to the fact that your assigned mass model does not have solid geometry in it. If you add some solid geometry to the assigned mass part model, then the calculations behave as expected (see the last screen shot). I have used assign mass but never in a part without some solid geometry in it and it has worked as expected for MP calculations. I believe the intent of assigned mass functionality is to be used for a model with some solid geometry. Please report back what the response is from PTC support when you get an answer.

[RandyJones]

---

@tbraxton wrote:

Using Creo 7.0.9 I get these results using your test models. It appears that something is not right with the way this works (unless PTC has documented why this is happening). I saw nothing in the help files that explains why these results are not as expected. 

I suspect it is working to PTC specification due to the fact that your assigned mass model does not have solid geometry in it. If you add some solid geometry to the assigned mass part model, then the calculations behave as expected (see the last screen shot).

---

If you add a value to assigned volume the calculations behave as expected, using the assigned mass and not the value you get from volume x density. See below for a response from PTC on how the mass is being calculated.

---

@tbraxton wrote:

I believe the intent of assigned mass functionality is to be used for a model with some solid geometry.

---

Many times we get step files from vendors that are complete surfaces so we add an assigned mass to these and we don't care about the volume or the density.

---

@tbraxton wrote:

Please report back what the response is from PTC support when you get an answer.

---

This is still in process. However this is one of those cases where some of the responses are very questionable. From the TS:

=================================================================================================================================================================

I received an update from the R&D team, and the team is saying:

"Mass is calculated using volume and average density. When using an assigned option in part mode and supplying 0 as volume, at the assembly level those values are used to calculate the mass (mass = mp_ptr->volume * mp_ptr->aver_density;) when selected as geometry. Which result returns Mass as 0."

Right now, in part ASSIGNED-MASS.prt, PRO_MP_ALT_Volume is not defined, hence showing the issue. Also suggested was the following workaround:

1. Open part ASSIGNED-MASS.prt
2. Tools >> Parameters >> Assigned mass properties >> Enter any value in ‘PRO_MP_ALT_Volume >> Regenerate

=================================================================================================================================================================

They obviously have not tried what they are stating because the mass is NOT calculated with assigned volume x assigned density. It is using the assigned mass value as I would expect it to.

[tbraxton]

When I have used assigned mass, it is for lumped mass parameters in models that are used for dynamic mechanism analysis. When using the models, I have used a spherical solid geometry for them. Those spheres are then placed at the centroid of the component they represent for analysis. They have worked for mass properties in my experience. One of the reasons I think that PTC assumes there should be solid geometry is because many of the mass properties of a model depend on the geometry. If you consider centroid and moments of inertia as examples those are indeterminate without some volume of geometry used to make calculations.

You are using the functionality for weight (mass) which does not require a volume geometry to calculate but Creo treats the mass as part of the mass properties calculation in the context you are using it.

[MartinHanak]

---

@RandyJones wrote:

---

@tbraxton wrote:

Using Creo 7.0.9 I get these results using your test models. It appears that something is not right with the way this works (unless PTC has documented why this is happening). I saw nothing in the help files that explains why these results are not as expected. 

I suspect it is working to PTC specification due to the fact that your assigned mass model does not have solid geometry in it. If you add some solid geometry to the assigned mass part model, then the calculations behave as expected (see the last screen shot).

---

If you add a value to assigned volume the calculations behave as expected, using the assigned mass and not the value you get from volume x density. See below for a response from PTC on how the mass is being calculated.

---

@tbraxton wrote:

I believe the intent of assigned mass functionality is to be used for a model with some solid geometry.

---

Many times we get step files from vendors that are complete surfaces so we add an assigned mass to these and we don't care about the volume or the density.

---

@tbraxton wrote:

Please report back what the response is from PTC support when you get an answer.

---

This is still in process. However this is one of those cases where some of the responses are very questionable. From the TS:

=================================================================================================================================================================

I received an update from the R&D team, and the team is saying:

"Mass is calculated using volume and average density. When using an assigned option in part mode and supplying 0 as volume, at the assembly level those values are used to calculate the mass (mass = mp_ptr->volume * mp_ptr->aver_density;) when selected as geometry. Which result returns Mass as 0."

Right now, in part ASSIGNED-MASS.prt, PRO_MP_ALT_Volume is not defined, hence showing the issue. Also suggested was the following workaround:

1. Open part ASSIGNED-MASS.prt
2. Tools >> Parameters >> Assigned mass properties >> Enter any value in ‘PRO_MP_ALT_Volume >> Regenerate

=================================================================================================================================================================

They obviously have not tried what they are stating because the mass is NOT calculated with assigned volume x assigned density. It is using the assigned mass value as I would expect it to.

---

Hi,

because of the fact that the problem is related to VOLUME=0 I modified assigned-mass.prt as shown on following picture.

Note: I do not know whether it this trick make sense.

[RandyJones]

---

@MartinHanak wrote:

---

Hi,

because of the fact that the problem is related to VOLUME=0 I modified assigned-mass.prt as shown on following picture.

Note: I do not know whether it this trick make sense.

---

This is the workaround we are using which is to assign a dummy value for the assigned volume. And like you say this trick does not make sense.

[StephenW]

I gave up on assigned mass some time back when it didn't do what I wanted. I don't remember what the specifics were of my frustration.

When I have surface models, I typically will just go add a "mass" at the cg and adjust the density so I get the correct mass and CG location. 

I'm one of those people who send out surface only models in an effort to reduce possibility of giving away too much information.

[Chris3]

PTC told me at one point in order to save calculation time and memory that they programmed mp_calc_level to all_models to just eliminate all models with 0 volume. Presumably they thought that people didn't care about those items so they just left them out of the report. This can be incredibly frustrating if the reason you are running that report is to find those components.

Its possible that your issue may be related to that. As @StephenW mentioned partly for this reason we try not to assign mass. Instead you can set the density with a relation:

MP_DENSITY=10/PRO_MP_VOLUME

where 10 is the mass you want the part to be. If its an assembly you can import it as a part and then handle it that way (assuming you don't actually need it as an assembly).

[RandyJones · Accepted solution]

The latest from PTC Tech Support is this:

"The R&D team has formulated a problem statement (PS) to enhance the functionality of Creo Parametric. However, they have not provided a timeline for its implementation. As of now, we recommend using the workaround that was outlined in the previous email."

The workaround is to add a dummy volume value to the assigned mass properties which is what we are doing:

After doing this the asm mass now is showing the mass of the assigned-mass.prt as expected. It is using the assigned mass (as I would expect) vs the mass you get from the density x volume:

So PTC is refusing to call this a bug however instead calling this a "problem statement (PS) to enhance the functionality of Creo Parametric".  Which is not yet documented in the article CS396826.

So far the only documentation of this is in the case I have open with them.

[Chris3]

I have opened tickets for this exact reason in the past as well and they refused to call it a bug and fix it. They called it "working to spec" which is outrageous. Who would write a spec that says that.

[TomU]

You misunderstand what 'working to spec' means to PTC.  If a spec to describe a function *does not explicitly state* that it needs to work (or not work) a certain way, then by definition it is 'working to spec', regardless of how illogical the behavior might be.  The developers simply do what they are told to.  They do not use the software for a living.

[ByDesign]

@TomU  you are right on target.  Then, to make matters worse, the Product Managers that write the spec don't use the software either.  For the last 20 years they just keep dumbing it down because those in charge don't know the value of what they are cutting out.

But, you know they are continuing to do a great job of losing market share!

[ByDesign]

To answer your question, yes, it is a bug.  However, PTC would much rather whitewash it than fix it.  So, since they gave a workaround, they can avoid fixing it.  It does not matter to them that the next person will come along with the same issue and waste a bunch of time to eventually have the same result.  This just shows again that PTC does not care about customers.  They certainly have no respect for our time when dealing with their bugs.