nonlin analyse, 2 load steps, cumulative iteration 1

[SKJoe]

Hi,

I run nonlinear analyse with 2 load steps. In first load step I applied a load and one CP set is used (LSWRITE,1). In second load step another load is applied and the CP set is removed (LSWRITE,2). Then LSSOLVE,1,2.

In postprocessor phase I animate deformation over the load steps and obtain following :

*** WARNING *** CP = 2159.031 TIME= 12:01:17
Cumulative iteration 4 may have been solved using different model or
boundary condition data than currently stored. POST1 results may be
erroneous unless you RESUME from a Jobname.DB file for this substep.

What does it mean ?

Regards,
Lubo

 

[ansysfreak]

Hi

Did you use the lsclear command.

Grtz
Garry

 

[SKJoe]

No, I didnt, but I think lsclear is used only when you want to obtain response of model for various loads independedly - not in meaning of nonlinear analyse. I examined a part of code for nolinear analyse from ansys manual and there were loads applied subsequently for each time without lsclear : 8.13. Sample Nonlinear Analysis (Command or Batch Method) :

! Start Cycle 1
! ----------------
nsel,s,node,,ntop
f,all,fy,-f ! Define load for load step 2
nsel,all
nsubst,4,25,2 ! Set the number of substeps, max and min number
! of substeps
solve ! Solve load step 2

nsel,s,node,,ntop
f,all,fy,f ! Define load for load step 3
nsel,all
nsubst,4,25,2 ! Set the number of substeps, max and min number
! of substeps
solve ! Solve load step 3


And if I prescribe above code to my case it is something like this :

! Start Cycle 1
! ----------------
nsel,s,node,,ntop
f,all,fy,-f ! Define load for load step 1
nsel,all
nsubst,4,25,2 ! Set the number of substeps, max and min number
! of substeps
lswrite,1 ! write load step 1

/prep7
CPDELE,1,1,1,ANY ! cp set removed
/sol

nsel,s,node,,ntop
f,all,fy,f ! Define load for load step 2
nsel,all
nsubst,4,25,2 ! Set the number of substeps, max and min number
! of substeps
lswrite,2 ! write load step 2

LSSOLVE,1,2

 

[Stringmaker]

Lubo,
You get a very similar message whenever your *.db and *.rst files have different jobnames as well. It's only a warning message and in most cases probably has no real merit. Just verify that your results make sense depending on the load step you're looking at and the boundary conditions you have applied for it. I think you'll be fine.

-Brian

 

[SKJoe]

Thank you a lot Brian, I hoped that answer to my question will be as you wrote.

Lubo

 

[cbrn]

Hi,
I confirm what Brian says: the message indicates that your database file contains a set of BCs which is different from the one stored in the results file (for the second loadstep, in your case). In effect, you tell us that you remove a CP. If you saved model+loads in the database prior to executing the change in the BCs, then database will have the BCs corresponding to the first LS while the results file will have, at the end, two sections corresponding to the two different LS, so the message will be issued whenever you do this sequence (other sequences with the same result may exist):
- load database
- call postprocessor
- load result file
- read last loadstep (i.e. the one that is different from database).

Hope I haven't been too confused...

In order to avoid this message, when you plan to have several different LS you'd better NOT save any load pattern inside the database.

Regards

 

[SKJoe]

Hi, it is me again,

Thank you too cbrn. Actualy I am not interested in whether this warning message pop ups or not. I am only interested in whether my results are valid or not. Or if there is a better way to do such changes over load steps. So when I postprocess results over these two load steps and I want to know only final value (not history of loading)it is better postprocess with db corresponding to second load step ? And in the same time this means that results for first load step (history of loading) are not correct ? You mentioned that :

"In order to avoid this message, when you plan to have several different LS you'd better NOT save any load pattern inside the database."

But I dont understand how to make these changes in different way. I dont understand how to make these changes outside of the database (I hope it is not cause of my poor english).

Is there any way to postprocess the results over these two load steps with two db files ? And it is better way ? Or it is better way to postprocess with db corresponding to second load step ?

And there is another problem : when I examined animation of deformation of my model over the load steps I realized that maybe I will have to change stiffness of one part of my model in some way as well. I know from manual of ansys regarding lswrite, that changes of material properties and changes of real constants are not written to file with load step. So I tried to change geometry via NMODIF to enlarge one part of model, but it didnt work. So is there any trick to change a stiffness in some way to be written in file with loadstep ?

Regards,
Lubo

 

[cbrn]

Hi,
as regards loads, there is redundancy because they are saved in the result file and, if you issue a "save" command in preprocessor, also in the database. As far as I know, having the database in memory during post-processing only brings extra info about FE model, not anything related to the calculation in itself. You can, for example, open the interface without issueing "resume from...", call post-pro, load result file only, recall the desired loadstep: you will have a note message saying that the FE data will be retrieved based upon what is stored in the result file, and that this FE data may be incomplete, but your results DO ARE complete, your elems are present, your nodes also, etc etc. So you can be assured about the reliability of your results.
Honestly, I never had to change elem properties between steps, so I can't be extremely precise on this, but I desume that, if you don't save the db and run the calculation, you will have that:
- the results correctly refer to the FE model status you had just prior to launching solution for that step
- you will have lost the info about the db status at that point.

Regards