Important bugs found for time dependent pressure and gravity with CCX.

Victor

If you use CalculiX through Mecway with pressure or gravity loads that are a function of time then these bugs might be affecting your results. When more than one pressure exists on the same face or more than one gravity load in the same model, then they must be constant, not time dependent.

It comes from a limitation in CCX which wasn't being checked for by Mecway. That is, *DLOAD with AMPLITUDE is limited to a single *AMPLITUDE for pressure on each element face and a single *AMPLITUDE for gravity in each direction.

CCX has similar limitations for *CLOAD, *CFLUX, and *FILM but these are OK because Mecway combines multiple time dependent forces into a correct set of *CLOAD cards and it shows an error message if you try to combine time dependent heat fluxes for *CFLUX or multiple convections for *FILM.

Listed as Bug 11 and Bug 12 here http://mecway.com/product.html#bugs

Thanks A.B. for discovering this.

Andrea

I have to try this case with Mecway but I saw that Mecway writes combination of *DLOAD and *Amplitude in a wrong way. In fact the reference value of a pressure or a gravity is 1 and the amplitude value is the reference value. (are inverted) Maybe could cause problems (see CCX manual sec. 7.1)

I repeat that I have to try this case with Mecway so I'm not sure if I'm right but I'm sure that Mecway doesn't treat correctly *AMPLITUDE card, above all with *CLOAD (every node load creates an amplitude card).

Victor

You're right on the facts - Mecway writes a reference value of 1 and puts the actual data in the *AMPLITUDE block. It also makes a separate *CLOAD card for each node and DOF. However, I haven't found any evidence that this is wrong. I did it to simplify the code and avoid anticipating and checking for various complicated special cases. Not having special cases means fewer tests are needed.

As far as I know, *CLOAD is always correct. If you find it's not and doesn't show an error message, please tell me because it would be a serious bug. It's not very human readable but it works around limitations of CCX to provide the same flexibility as the internal solver. For example, if you have multiple time dependent force loads sharing some common nodes, CCX doesn't allow that directly, but Mecway does because it creates different *CLOAD cards for those common nodes with the force vectors already summed in their *AMPLITUDE blocks. It also corrects for *TRANSFORM caused by constraints in odd directions which would normally change the direction of the *CLOAD force.

Andrea

Is it possible to have an example that shows clearly wrong results in strucrural field?

Regards

Victor

Here's a plate with two opposing pressure loads. One is constant and the other increases with time. Deflection should start at a maximum then decrease to zero as the opposing pressures balance. Due to the bug, the deflection is constant and nonzero through all time.

Andrea

OK!
Is not a bug is the same principle applied by ABAQUS.
This happens also creating 2 or more steps. Same load applied to the same entity is replaced with the new load, also selecting OP=MOD (As a default)

Attached picture explain the principle

So if you want to apply a load composed by a steady component and a variable one you must define only one amplitude card. I think that's reasonable

Regards

Andrea

Here the solution inverting loads sequence and the right solution

Victor

Yea, it's part of the design of CCX too so I call it a bug in Mecway, not in CCX.

I think the pressure on Correct.liml should be from -1 to 0 instead of 1 to 2 because the constant pressure is in the opposite direction to the variable one. I changed it in Correct2.liml attached here.

In version 8, both Inverted.liml and Correct2.liml will produce identical solutions because it'll use *DSLOAD instead of *DLOAD. *DSLOAD allows a different amplitude on each face of a shell element whereas *DLOAD only has a single "P" face.

Andrea

Will remain the problem about *CLOAD. So two different strategies could cause confusion.

PS Maybe is not always simple to create the same algorithm for two different solvers. inp file generated by Mecway is often difficult to manipulate manually. Have you think about generation of more inp with include?

Victor

It shouldn't be confusing if you don't know anything about CCX :P The general rule for Mecway is that multiple values are summed where that's the obvious thing to do and an error where it's not. In cases where it can't yet sum them, it also shows an error message. So to have correct results, you don't need to learn the details of how each thing is converted and how CCX treats multiple values.

Is the *CLOAD problem that it's too complicated to read with so many separate cards? Also about include files, it's not really my aim to make a user-readable .inp file. I know that would be a nice extra and I try to do that where it doesn't add complexity to the code. However, my priority is improving the functionality available through the UI to reduce the need to look at the .inp file.

Andrea

OK! I have understand your priority but I have another point of view because I work every day not for me but for third party. So inp file is a foundamental part of the technical file with the calculation reports because it contains all the information about the model simulation. If a third party ask me FEA calculation what can I present?
inp is fully compatible with Abaqus and importable in most FEA software. It' important that's more simple as possible.

Other aspect is my idea about FEA simulation. I think that in the future will be stricly necessary that all FEA softwares have a common input format that can be imported. Is the same necessity of CAD file format, i.e. step file which is standardize by ISO.

Regards

Victor

Oh, that's an entirely different reason! I didn't know anybody was sharing the generated .inp files. I've added simplifying .inp to my list now. Hopefully at least some separate files or reducing redundant *AMPLITUDE cards.

Sergio

I also use a lot of sharing inp (or at least import/export/fine tuning), so it makes a little complex to see forces or pressures applied to each node or element face.

Andrea, one thing that sometime did for improve the reading of input file is generate the nodes/surfaces groups using the GUI, but apply the loads as a custom edit, in that way I could keep the generated input file more "human readable" and in the way that I did for years in Abaqus or others (because I found that sometimes Mecway didn´t behave the way I expected). Best thing to me is keep the bc/materials cards in separated files from node/element/groups, so you can concentrate in just 10-20 lines of code.


One idea to improve this situation could be, if the user has applied the bc on a previously created group (name selection), then the input file could reflect that, and if the user has selected directly the nodes at the bc creation, then it could be writted per node/face as is now.

In my opinion more and more people will see Mecway as a prepo for CCX, and probably they will arrive after sometime writting by hand the cards (my case), so having the cards writted in the actual way could be a little weird.

Best regards.

Victor

I've tried to have it use the groups that the user specified when it's always right. For example, *FILM does that. Unfortunately, it's not possible in general for most BCs because of the issues like in my 1st and 2nd post above. It could still do better though and at least group what it can together.

Sergio

One thing that we as user must recognize is that this kind of problem is not only related to Mecway alone, Abaqus itself has the same behaviour sometimes (the inp files that Abaqus CAE generate are not so easy to read by human eye, or worst thing some new cards are not supported by the GUI but the solver, and weird things such as you run a problem directly from inp in command line ands gives completely different result as if you import the inp in CAE and run by the GUI...the importer treat different the card as the solver...), surely as they face the same problems as Victor says, the program must be able to write any obscure combination of bc that a crazy user would like to use (or worst thing, a user trying to make it fail the program), and doing that is at cost of writing the inp in a no traditional way.

Regards