Density to Mass Conversion (Modal Analysis)

Feature Requests
1

Hey all,

Just fought through an issue in regards to a modal analysis with suspicious results, compared to hand calcs and other solvers and finally got the expected result… Which leads me to asking for this feature.

Basically, modal analysis is expecting density to be in units of mass. When your default unit system is in, lb, s, etc., density is in units of force (lbf/in^3). When performing a modal analysis, you have to change density units to slinches (slug-inches, manually). Most modern solvers will do this automatically on the back-end and we don’t think about it. NASTRAN makes you keep track of this, and requires the input “WTMASS” on the analysis setup. “WTMASS” is simply scaling your density units from force (lb), to mass (slinch), for this conversion, the value is 1/386.1.

Is it possible to implement a similar scaling option somewhere? Honestly just having another entry box in step setup would be perfectly fine.

image
image331×550 6.36 KB

Although it’s fine to track this manually and just enter density as units of slinches, it can get tedious. If the goal is that PrePoMax is unit aware, then something like this should be implemented eventually (either back-end and automatic, or entry box).

EDIT: Should also add that I feel like this is the purpose of the “gravitational constant” input box, but please correct me if I’m wrong about that. However, changing the gravitational constant has no effect on the results.

Feature Request list
Issues with linear buckling analysis following ASME PTB-2022 example problem
Gravity load shows excessive results
2

I’m totally unfamiliar with these units but here’s a reference based on what is suggested in Abaqus documentation:

abq units
abq units1182×407 17.1 KB

Gravity load shows excessive results
3

Yes, if you look in this table under the US unit (inch), the mass and density are in units of slug-inches. It isn’t called that in the table, but it’s listing the base units.

As I said, it’s totally acceptable to track this manually and just remember to change your density on the material card. But it’s a bit painful to remember to change this value when the US units are prompting you to enter in units of lbf/in^3.

Does this request make sense? If not I can put together a simple example and show the hand calcs to show you what generates the error. US units are pretty odd when you get into things like this. I just feel like if the goal is for PrePoMax to be unit aware, users shouldn’t be tracking density conversions themselves. Otherwise it should just always be ran unitless.

4

As I understand the unit awareness of Prepomax, it just tells you what units to use for input and what units to expect in output, providing several sets of consistent units.

A more advanced unit interface would let the user select the unit of input values and then do conversion as appropriate. This could be done by adding dropdown selectors to any numeric input field (or to a subset, based on user requests).

As long as that is not implemented, you have to use your favorite conversion tool. I use SMath Studio for this purpose:

image

5

Thanks for pointing that out. I have no idea how the US units work so I had multiple headaches implementing the units as they are. I chose the consistent units as good as I could. So what you are trying to explain is that for other uses the density lb/in^3 is OK but not for frequency calculations? And that is the only exception?

There is no problem implementing the scaling factor I only want to understand when it needs to be accounted for.

I selected the available unit systems in such a way, that the values inside PrePoMax are the same as the values in the .inp file. In that way, the user is not confused when editing the .inp file. That is why I only supported consistent unit systems and I did not support any arbitrary combination of units. But that does not mean that the user must enter the units in the unit suggested by the input box. Any supported unit can be entered int the text boxes and then they are automatically converted to the selected unit system. So for example, the length can be entered in mm, cm, m, km, in, ft, … with no regard to the selected unit system inside PrePoMax.

6

A consistent imperial system is slug for mass, feet for length, seconds for time and lbf for force. That’s what slug has been invented for or how it is defined.

image

BTW: in SMath Studio results are displayed as a product of value times unit. In the given example I display 1 lbf in units of slug times inch. The resulting value is 1/s^2, which is proof of consistency (no numeric factor remaining).

So the consistent unit of density would be slug / cube feet. If you want to provide an inch based system, then just apply the appropriate conversion

image

7

Thank you Martin for this explanation. I definitely only want to support consistent units (in order to use them with the same values in the .inp file) and thought that inch based system is more common that feet based system. I would rather support only one US unit system for the moment :slight_smile:

8

TLDR; Broader discussion on unit system is needed before one-off solutions should be implemented.

@Matej , I totally agree with what you’re saying, and think the approach you took was valid. @mkraska, length units should be consistent with the unit system selected. In my case, slugs and inches should be used. Using feet as the length measurement would also be disruptive.

It sounds like no immediate action should be taken here. I feel like there’s a larger discussion regarding unit systems in general that should be had before we start implementing one-off solutions. I think the best course of action is deciding how PrePoMax should handle units at a higher level, and then dive into specific cases like force to mass conversions on the density side. The reason I feel like a broader discussion is needed is because I’ve noticed other inconsistencies with units (such as material libraries not converting between unit systems). The real “issue” here is that PrePoMax frames itself as being unit aware, when in reality it is not. The selected unit system simply serves as a guide for users, but does no conversion on the back end to ensure unit systems are consistent. I sort of feel like this is counterintuitive, which is why several pre-processors only support a unitless system and forces users to track these things manually.

If there’s agreement here that some action should be taken, I’m happy to discuss this more. Otherwise we should maybe close this thread out and start another that’s just a general “units discussion” feature request.

9

I guess you also want to insist on force unit being lbf, so that stresses and youngs modulus are in psi.

This implies a special time unit:
image

10

If US units are to be consistent with what is actually used, yes. That is why I said that we should probably put this on hold now. There’s a bit of a larger “issue” at play here and it’s gets pretty involved on the US units side of things (US units are stupid, I know).

If a true US units system was to be implemented, things like this have to be worked through. I personally think it may be worth the effort down the road, but currently it’s probably a larger headache than it’s worth given other requests and demand.

11

If the only thing that has to be scaled in the current US unit system in PrePoMax is the density for the frequency calculation, I can add an additional scaling factor in the step definition. But now I am not sure if other physical quantities have appropriate - consistent units. Like energy and thermal quantities.

12

Hey Matej, I just happened to check in on PrePoMax today and noticed the new dev version with slinches incorporated for mass. Did a couple sanity checks and got alignment with NASTRAN results within 1% for modal analysis. This is great, awesome work! Happy to send over results if you need anything for reference.

Some comments for reference incase other users have issues:

  1. Don’t use even more weird US units (like feet), it’s going to cause weird things on the backend with mass.
  2. Remember to scale geometry by 1/25.4 - PrePoMax imports everything as mm by default.
  3. Material input cards for US system are only accepting slinches now (sluginches/s^2). This is a little non-standard as technically slugs are in slugft/s^2. This is not an issue at all, just know what you’re using.
  4. US units are silly!
  5. If all else fails, convert everything to SI as the software seems to do a great job.
1 Like
13

For the mass, I selected the unit lbf⋅s^2/in since the length has a unit of in. Looking at the definition of a slug (Wiki): lbf⋅s^2/ft this is now not the same. But in order to be consistent, I think lbf⋅s^2/in must be used (please correct me if I am wrong). I try to use consistent units in PrePoMax in order to have the same values that are entered in the GUI appear in the .inp file/Keywords editor.

14

I think that the path you have chosen is the correct approach, as ultimately the mass needs to be converted to slug*s^2/in (slinch) for the solver to have a correct set of units.

I was just trying to highlight to others that they can’t just pull the density of their material in slug, enter it into PrePoMax, and start solving. There’s nothing wrong with the currently implemented approach, as NASTRAN/ABAQUS force you to do the same thing.

Just wanted to highlight this to folks who may not be as familiar with US units!

I am leaving my original comment as is, but what I really mean is:
slug*s^2/in isn’t the “standard” US mass unit, but is correct for the purposes of FEA where length is inch based. Sorry for any confusion.

1 Like