Welcome to the forums. Please post in English or French.

You are not logged in.

#2 Re: Code_Aster usage » How to view principal strains/stresess » 2011-05-30 06:37:21

Thank Thomas.

That looks like a useful feature.

Todd.

#3 Re: Code_Aster usage » Von misses Stress in 3D_DKT modal analisis » 2011-05-27 06:05:03

Hi udc_Stdnt

I have raised this issue before here
http://www.code-aster.org/forum2/viewtopic.php?id=14646

Since then it has been quietly forgotten.

The only work-around I can suggest is to output the stresses/strains (SIGM_ELNO_DEPL,EPSI_ELNO_DEPL) for the plate and solid elements in gmesh format as a 3D tensor.

IMPR_RESU(FORMAT='GMSH',
          RESU=(_F(RESULTAT=solution,
                   TYPE_CHAM='TENS_3D',
                   NOM_CMP=('EPXX','EPYY','EPZZ','EPXY','EPXZ','EPYZ',),),),);

Then calculate the principal stresses/strains within gmesh using the EIGENVALUES/EIGENVECTORS plugin.

This should also be possible in Paraview, using Ensight output, but I haven't tried it.

Todd

#4 Re: Code_Aster usage » Rotation Modelling » 2011-05-23 03:08:21

Hi Richard

Your best bet might be to model the entire structure and forget the cyclical symmetry constraints.

Todd.

#5 Re: Code_Aster usage » Rotation Modelling » 2011-05-19 12:45:17

Hi Richard

You have over-constrained the problem.

My guess is that the cylindrical axis contains nodes which have been constrained by the LIAISON_CYCL command for both surfaces (FACE1 & FACE2) of the wedge. This causes a singular matrix, so the solver fails.

Remove the duplicate nodes from one group (either FACE1 or FACE2) and it should work.

Cheers,
Todd.

#6 Re: Code_Aster usage » Solver unreasonably slow for composites » 2011-05-04 23:29:17

Hi Thomas

Thanks for the subroutine information. I will have a look at it, when I get a chance.

Todd.

#7 Re: Code_Aster usage » [?] most stable way to model surfacic rigid body in Aster? » 2011-05-04 06:44:04

Hi Pierre

=> why don't you skip the "pin" node, discrete mass, and LIAISON_SOLIDE and directly apply rotation and translation constraints on "bulkhead" group?

In this case the pin and LIAISON_SOLID is unnecessary, but it is a technique I use for convenience, so that the bulkhead nodes are constrained to rotate around a particular point.

I usually know the applied force at the centre of the cross-section (extracted from a beam model). In some cases I need to apply loads and moments to the top of the tube. In other cases I want to constrain the pin, so that it moves vertically, but not horizontally, for example, and extract the reactions. The discrete mass is fictitious, but is there to satisfy code-aster.

I think to understand your modelling but the use of AFFE_CHAR_CINE is here for a still rigid body (not a moving one through which is applied a force).

Thomas should be able to answer this better than me. A motion can be applied to the rigid body by specifying a non-zero displacement, possibly using a ramp function.

Todd.

#8 Re: Code_Aster usage » [?] most stable way to model surfacic rigid body in Aster? » 2011-05-04 03:12:54

Hi Pierre

Have a look at the attached COMM file, to see how I modelled a rigid curved surface for contact.
Particularly the keyword AFFE_CHAR_CINE.

Todd.

#9 Re: Code_Aster usage » Solver unreasonably slow for composites » 2011-05-02 06:30:40

Upon further consideration, D2 could also be calculated and stored for each laminate at the same time as D1. It would provide a fast way to calculate Hct and emit a warning for elements with incorrect shear energy. Of course, when D2=0 no checks would be required.

#10 Re: Code_Aster usage » Solver unreasonably slow for composites » 2011-04-27 01:46:54

Hi Thomas

Not that I've had time to read R3.07.03 again, I have some suggestions.

In the case of the DKT models, a solution is obtained for zero through-thickness shear strain, so anyone running such a model should not be interested in through-thickness shear stresses. It seems logical to me that calculating an average shear stress, by dividing the resultant (equilibrium) shear force by the laminate thickness would suffice in this case, since the computational expense of performing a numerical integration across multiple layers is too great.

When one is interested in through-thickness shear stresses, one should run a DST model. However, I believe a numerical integration is also unnecessary here, as an analytical integration has already been performed. I hope I can explain my argument clearly in this post, without the detailed mathematical equations.

Referring to the Annexe 2 in R3.07.03 we see that the assumption is made that Hct = C11(-1) and that for a non-homegenous (possibly non-symmetric) laminate C11 can be calculated by a summation. This summation represents an analytical layer by later integration of the D1 equation. Therefore the through-thickness shear stress in each ply can be calculated directly from the shear force resultant, T, if the D1 value is retained at each layer. In other words, an analytical integration is performed for each laminate (but not each element) during the construction of the Hct matrix early on in the solution process. I suggest storing these D1 values, possibly 3 (bottom,middle,top), for each layer and using them to calculate the shear stress in each layer after generating a solution. This should be very fast. It would also be valid with or without plate offset, unless the model equilibrium is being invalidated by plate offset. I sincerely hope that is not the case.

Considering the example problem I attached previously for an isotropic plate with 100 layers, the Hct=C11(-1) assumption is valid and the solution time would not be much greater than that required for the single layer plate.

Of course, the assumption Hct=C11(-1) is not always valid, but a significant difference between the calculated and expected shear energy would require a re-solve anyway, where Hct and D2 are calculated element by element. This could be an optional, albeit slow, extra step. In the abscence of this, the solver could simply emit a warning, if the calculated shear enegy differs from that expected by a "user-defined" percentage. So, when there is no warning, there would be no need to calculate D2 and the results would be accurate enough with no need for numerical integration. Does this make sense?

#11 Re: Code_Aster usage » Incorrect nodal forces with plate offset. » 2011-04-08 04:37:07

Hi Thomas

Thomas DE SOZA wrote:

However there are things you need to know :

- Shear stress in Code_Aster cannot account for the change introduced by offset. Basically this means that the SIXZ and SIYZ components of the stress tensor computed by SIEF_ELGA/SIGM_ELNO option are not correct when offset is added (e.g. they do not verify the free border condition and are not zero).
- the Q4G element still has some problems with the computed stresses (a bug has been filed).

Since the shear stresses are parallel to the offset direction, ie. normal to the surface, why is the free surface condition unsatisfied?

Thomas DE SOZA wrote:

Since the FORC_NODA field is computed by mean of the SIEF_ELGA field this explains the problem with nodal forces and offset. Note however that nodal forces do not have any physical meaning (except of course when they are summed) and one usually prefers using the stress tensor or the generalized stresses for structural elements.

Summed over what? If I weld a cylindrical shell to a solid hemi-sphere and then press that solid against a rigid surface, can I not reliably extract the nodal force distribution transferred from the solid to the base of the cylindrical shell?

#12 Re: Code_Aster usage » Solver unreasonably slow for composites » 2011-04-08 01:28:18

Hi Thomas

Thanks for the information.

It seems to me, since the shear stress is zero on both free surfaces, the most expensive calculation should be for the middle layers, as integration can be started from either the top or the bottom surface. The current method of always starting the integration from layer 1 makes the calculation of the first layer very fast and the last layer very slow. Surely this can be fairly easily fixed by starting the integration at the free surface closest to the requested layer. In this way speed of calculation layer 1 = layer N, layer 2 = layer N-1 etc.

The integration of the through thickness shear stress, layer by layer, is a useful feature for ply "strength" calculation. (My Nastran solver just calculates a weighted shear force resultant, corresponding to a constant strain, and divides it evenly across the layers.) However, most of the time I am not interested in observing the stresses/strains in each layer. Instead I essentially want to model a homogenous anisotropic plate and observe the strains at the free surfaces. I am wondering whether ELAS_COQUE could be used for this. See this link http://www.code-aster.org/forum2/viewtopic.php?id=13674

Thanks,
Todd.

#13 Re: Code_Aster usage » Paraview ok on Windows, but fails on Linux » 2011-04-05 23:49:06

Hi AsterNoob

Were those files created on windows? I would check the line endings on any text files and convert them if necessary.

Todd.

#14 Re: Code_Aster usage » [solved] contact method compatibility with parallelism » 2011-04-05 23:45:58

Hi

Just for clarity. Does parallelism work for dual/quad-core processors or just machines with multiple single-core processors on the motherboard?

Todd.

#15 Re: Code_Aster usage » CA equivalent for RBE2 and RBE3 » 2011-03-27 22:39:13

Hi JMB365

Regarding LIAISON_ELEM. It is my understanding that, if the force is vertical, the load is uniformly distributed to the nodes. If it is horizontal the forces are distributed such that the bending moment and shear force is applied with the vertical reactions varying linearly along the nodes (maximum at the extremities) and the horizontal reactions uniformly distributed. So the reactions are weighted like those in a bolted/riveted joint.

The best way to find out would be to build a simple model and test it by observing the nodal reactions using CALC_NO
                OPTION=('FORC_NODA','REAC_NODA',)


Todd.

#16 Re: Code_Aster usage » CA equivalent for RBE2 and RBE3 » 2011-03-26 02:46:23

Hi JMB

The closest thing CA has to RBE2 is LIAISON_SOLID, but it constrains all DOFs on the dependent nodes.

One of the nice things about RBE2 elements is the ability to pick and choose which translation/rotation DOFs to constrain on the dependent nodes and which coordinate system (cartesian,cylilndrical,spherical) to use for imposing those constraints. So, for example, a part can be constrained to slide on the surface of a pin by restraining the radial component of the dependent nodes using a cylindrical coordinate system defined on the axis of the pin. This is a problem in CA, since CA does not have a coordinate system object.

The RBE2 is actually just a series of multi-point constraints, defined in global cartesian space, between the dependent nodes and the independent node. So it can be fully replicated in CA for specific DOFs using LIAISON_DDL. As others have commented, this is tedious and error prone, if you must do it by hand.

RBE3 elements transfer load, but not stiffness from the independent to the dependent nodes. This can be achieved in CA using LIAISON_ELEM from a beam to a solid, or a beam to a shell.

Todd.

#17 Re: Code_Aster usage » Solver unreasonably slow for composites » 2011-03-25 05:44:50

Hi

I am raising this issue again, as there has been no response regarding a solution.

I am trying to solve a real world problem with a 40 layer anisotropic laminate and 90k plate elements. The solution time in MECA_STATIQUE is 10mins, but when I tried to calculate element results using CALC_ELEM on the inner and outer surfaces the solver did not finish after 1.5hrs. I am running a dual core T7500 2.2Ghz machine with 2Gb ram. This is a show stopper.

The same problem solves in 10 minutes with my Nastran solver on a Pentium 4 2.4GHz machine with 1Gb ram.

So I created 3 simplified models with 1/10/100 layers in a 10mm thick Aluminium laminate respectively. As you can see the solution time climbs from 3.89s to 538.22s, when it should remain almost constant.

Is the solver trying to integrate through more and more layers as the count increases? Please view the attached models and results files.

With 1 layer

********************************************************************************
* COMMAND                  :       USER :     SYSTEM :   USER+SYS :    ELAPSED *
********************************************************************************
* init (jdc)               :       1.64 :       0.10 :       1.74 :       1.85 *
*  . compile               :       0.01 :       0.00 :       0.01 :       0.00 *
*  . exec_compile          :       0.14 :       0.00 :       0.14 :       0.15 *
*  . report                :       0.01 :       0.00 :       0.01 :       0.01 *
*  . build                 :       0.00 :       0.00 :       0.00 :       0.00 *
* DEBUT                    :       0.03 :       0.05 :       0.08 :       0.63 *
* LIRE_MAILLAGE            :       0.04 :       0.01 :       0.05 :       0.66 *
* DEFI_GROUP               :       0.02 :       0.00 :       0.02 :       0.03 *
* AFFE_MODELE              :       0.01 :       0.01 :       0.02 :       0.19 *
* DEFI_MATERIAU            :       0.01 :       0.00 :       0.01 :       0.04 *
* DEFI_COQU_MULT           :       0.00 :       0.00 :       0.00 :       0.00 *
* AFFE_MATERIAU            :       0.01 :       0.00 :       0.01 :       0.03 *
* AFFE_CARA_ELEM           :       0.10 :       0.00 :       0.10 :       0.25 *
* AFFE_CHAR_MECA           :       0.12 :       0.00 :       0.12 :       0.22 *
* MECA_STATIQUE            :       0.79 :       0.05 :       0.84 :       1.36 *
* CALC_ELEM                :       0.31 :       0.00 :       0.31 :       0.32 *
* CALC_ELEM                :       0.29 :       0.00 :       0.29 :       0.31 *
* IMPR_RESU                :       0.20 :       0.00 :       0.20 :       0.20 *
* FIN                      :       0.02 :       0.05 :       0.07 :       0.09 *
*  . part Superviseur      :       1.68 :       0.16 :       1.84 :       2.64 *
*  . part Fortran          :       1.93 :       0.12 :       2.05 :       3.67 *
********************************************************************************
* TOTAL_JOB                :       3.61 :       0.28 :       3.89 :       6.34 *
********************************************************************************

with 10 layers

********************************************************************************
* COMMAND                  :       USER :     SYSTEM :   USER+SYS :    ELAPSED *
********************************************************************************
* init (jdc)               :       1.69 :       0.11 :       1.80 :       1.94 *
*  . compile               :       0.01 :       0.00 :       0.01 :       0.01 *
*  . exec_compile          :       0.14 :       0.00 :       0.14 :       0.15 *
*  . report                :       0.02 :       0.00 :       0.02 :       0.01 *
*  . build                 :       0.00 :       0.00 :       0.00 :       0.00 *
* DEBUT                    :       0.01 :       0.03 :       0.04 :       0.06 *
* LIRE_MAILLAGE            :       0.02 :       0.01 :       0.03 :       0.02 *
* DEFI_GROUP               :       0.01 :       0.00 :       0.01 :       0.01 *
* AFFE_MODELE              :       0.00 :       0.00 :       0.00 :       0.03 *
* DEFI_MATERIAU            :       0.00 :       0.00 :       0.00 :       0.00 *
* DEFI_COQU_MULT           :       0.00 :       0.00 :       0.00 :       0.00 *
* AFFE_MATERIAU            :       0.00 :       0.00 :       0.00 :       0.01 *
* AFFE_CARA_ELEM           :       0.06 :       0.00 :       0.06 :       0.07 *
* AFFE_CHAR_MECA           :       0.10 :       0.00 :       0.10 :       0.11 *
* MECA_STATIQUE            :       3.34 :       0.04 :       3.38 :       3.52 *
* CALC_ELEM                :       1.48 :       0.00 :       1.48 :       1.52 *
* CALC_ELEM                :       5.52 :       0.01 :       5.53 :       5.54 *
* IMPR_RESU                :       0.20 :       0.01 :       0.21 :       0.20 *
* FIN                      :       0.02 :       0.06 :       0.08 :       0.13 *
*  . part Superviseur      :       1.71 :       0.14 :       1.85 :       2.01 *
*  . part Fortran          :      10.76 :       0.13 :      10.89 :      11.16 *
********************************************************************************
* TOTAL_JOB                :      12.48 :       0.27 :      12.75 :      13.17 *
********************************************************************************

with 100 layers

********************************************************************************
* COMMAND                  :       USER :     SYSTEM :   USER+SYS :    ELAPSED *
********************************************************************************
* init (jdc)               :       1.65 :       0.12 :       1.77 :       1.77 *
*  . compile               :       0.01 :       0.00 :       0.01 :       0.01 *
*  . exec_compile          :       0.15 :       0.01 :       0.16 :       0.17 *
*  . report                :       0.04 :       0.00 :       0.04 :       0.03 *
*  . build                 :       0.00 :       0.00 :       0.00 :       0.00 *
* DEBUT                    :       0.02 :       0.03 :       0.05 :       0.05 *
* LIRE_MAILLAGE            :       0.02 :       0.01 :       0.03 :       0.02 *
* DEFI_GROUP               :       0.01 :       0.00 :       0.01 :       0.01 *
* AFFE_MODELE              :       0.00 :       0.00 :       0.00 :       0.01 *
* DEFI_MATERIAU            :       0.01 :       0.00 :       0.01 :       0.00 *
* DEFI_COQU_MULT           :       0.02 :       0.00 :       0.02 :       0.03 *
* AFFE_MATERIAU            :       0.01 :       0.00 :       0.01 :       0.00 *
* AFFE_CARA_ELEM           :       0.06 :       0.00 :       0.06 :       0.07 *
* AFFE_CHAR_MECA           :       0.11 :       0.00 :       0.11 :       0.10 *
* MECA_STATIQUE            :      86.79 :       0.18 :      86.97 :      88.05 *
* CALC_ELEM                :      13.53 :       0.04 :      13.57 :      13.77 *
* CALC_ELEM                :     434.63 :       0.50 :     435.13 :     441.19 *
* IMPR_RESU                :       0.23 :       0.01 :       0.24 :       1.14 *
* FIN                      :       0.06 :       0.18 :       0.24 :       0.88 *
*  . part Superviseur      :       1.68 :       0.15 :       1.83 :       1.84 *
*  . part Fortran          :     535.47 :       0.92 :     536.39 :     545.33 *
********************************************************************************
* TOTAL_JOB                :     537.15 :       1.07 :     538.22 :     547.17 *
********************************************************************************

#18 Re: Code_Aster usage » éléments distordus et REAC_NODA » 2011-03-20 23:04:27

Hi Pierre

pierre_j wrote:

Todd, have you ever thought to shift your modelling habits with shell elements to SHB elements?
The thing is that as they are solid elements, all the advanced features of Code_Aster for solid elements are available for SHB elements (or so I understand):
UMAT, GDEF_LOG, contact...

What do you think of it?
(I am myself trying the shift)

I hadn't considered using solid elements. For a laminate with n plies that would require n divisions through the thickness direction. I imagine it would become computationally unfeasible pretty quickly.


Thanks for the feedback Thomas!

Todd

#19 Re: Code_Aster usage » Using Abaqus input files in Code Aster » 2011-03-20 22:57:11

Nima wrote:

Have a look on Calculix's cgx. You can read inp files into Calculix and then export it in aster format. As far as I remember, you need to do it group by group.

I actually wrote a patch for Calculix, which was included in version 1.9. The latest version is 2.2

The command "send all aster" now generates a *.mail file with all the nodes and elements, as well as the node and element groups. You don't need to export each node/element group by name into separate files. Which was pretty useless anyway.

You need to go here
http://www.dhondt.de/
for the linux version, documentation and source.

#20 Re: Code_Aster usage » éléments distordus et REAC_NODA » 2011-03-17 07:58:49

Hi Claus

Claws wrote:

That forum post is mentioned in yesterdays changelog in case you didn't see it smile :
Claus

No I didn't see that. Thanks.
However, since there are no T3G elements yet, and COQUE_3D doesn't work with composites, I'm stuck between a rock and a hard place.

It also begs the question, "if DST is going to be deprecated, why fix PhL's bug next week?"

Todd.

#21 Re: Code_Aster usage » éléments distordus et REAC_NODA » 2011-03-16 23:22:19

Hi Thomas

Ce bug sera corrigé la semaine prochaine.

TdS

Is this bug related to this one?
http://www.code-aster.org/forum2/viewtopic.php?id=14645

Todd

#22 Re: Code_Aster usage » Bug Tracker and Source Control for Code-Aster » 2011-03-11 23:34:59

Hi nchauvat

Feel free to use http://www.python-science.org/project/libaster to track issues about code_aster.
The mercurial repository will be available next week at http://hg.python-science.org after Alain is done with the python training he is currently giving.

Thanks. Will the mercurial repository be hosting Eficas?

#23 Re: Code_Aster usage » Bug Tracker and Source Control for Code-Aster » 2011-03-11 23:32:35

Hi AsterO'dactyle

Code_Aster is not a web browser.

I don't understand your comment. Are you referring to BugZilla? It is used by

Free Software Projects

    * Mozilla: https://bugzilla.mozilla.org/
    * Linux Kernel: http://bugzilla.kernel.org/
    * Gnome: http://bugzilla.gnome.org/
    * KDE: http://bugs.kde.org/
    * Apache Project: http://issues.apache.org/bugzilla/
    * Open Office: http://www.openoffice.org/issues/query.cgi
    * Eclipse: http://bugs.eclipse.org/bugs/

Linux Distributions

    * Red Hat: https://bugzilla.redhat.com/bugzilla/
    * Mandriva: http://qa.mandriva.com/
    * Gentoo: http://bugs.gentoo.org/
    * Novell: https://bugzilla.novell.com/

Companies

    * NASA: http://itos.gsfc.nasa.gov/~bugzilla/
    * Facebook: http://bugs.developers.facebook.com/
    * Plus Akamai, Nokia, The New York Times, Yahoo! and many more

Todd.

#24 Code_Aster usage » Bug Tracker and Source Control for Code-Aster » 2011-03-10 23:59:32

todd_alan_martin
Replies: 5

Hi Christophe

I have created a new thread to link back to this discussion
http://www.code-aster.org/forum2/viewtopic.php?id=14943

Firstly let me say that my criticism of the lack of a bug-tracker and access to source control for code-aster is not a criticism of the huge effort made by EDF and their generosity in sharing their intellectual property with the public domain! I certainly appreciate that.

Christophe Durand wrote:

Indeed, what we call our inner « bug-tracker » is private and we do not plan to open it. Several companies or academic entities (other than EDF) have access to it but it is strictly framed by co-development agreements, with legal duties for the both parts.

What are the reasons for keeping EDF's bug-tracker private ?
- Most of the time, a bug report shows more or less of the study in object (attachments for bug replay). Showing EDF's computations, especially the ones connected to nuclear studies, cannot be considered.
- Our bug-tracker is also our tool for managing all the Code_Aster improvements. It is EDF's privilege to keep private the development plan of Code_Aster, our current subjects of technical interest and so on.
- Fixing the bugs related to EDF's engineering version of Code_Aster is a very strict duty for us, framed within a specific process. In spite of the great attention we pay to feedbacks from the open-source community, we cannot manage these bug alerts indistinctly from those coming from our engineering departments.

What could we do for helping the community ?
I agree with you concerning the awkwardness of using the forum threads as a vehicle for bug reports. A real opened bug-tracker would be more convenient. We are thinking about it. This is not a promise but the question will be examined with all the attention it deserves . Please note that this opened bug-tracker will be allways strictly distinct from the EDF's one for the reasons given above. You can see it as a displacement of a part of the forum towards a more convenient tool.

I would strongly recommend you look at Bugzilla as a bug-tracker. It is open source, created by Mozilla, and has features which allow you to restrict access to bug reports by users and groups. Also it can be hooked up to Git, Subversion and CVS repositories. These repositories also can have access restricted by user/group, depending on the application server chosen.

Christophe Durand wrote:

About EDF's interest in the composite models :
Well. Code_Aster, and the mechanical models it contains, is an image of EDF's subjects of interest, related to materials and structure that EDF has to deal with (nuclear powerplants, dams, turbine shafts ... ). So, in spite of being an all-purpose software in mechanics, Code_Aster has numerous forces (behaviours for steel and concrete, damage, contact ... ) and also weaknesses (including composites which are pretty rare in nuclear plants). As an open-source code, all the goodwills for improving or developping efficient finite elements for composites are obviously welcome.

This will certainly be facilitated with access to the source control and a bug-tracker.

I can tell you right now that I could internationalise the Eficas applciation in about 1 week, if I had access to a branch of the code. Then other users could easily create/edit translation files for each and every language. Not just french and english. I'm sure there are other users out there, who would appreciate that. While I can certainly patch my local copy immediately, (and I have already started this), I see no point in creating a version of Eficas which will not be merged into the source trunk. It would just become a maintenance nightmare.

Apart from having a Ph.D. in mechanical engineering, I have also worked in commercial software development (not just in an academic/scientific environment). By restricting access to the source code and a bug-tracker you are hobbling the efforts of those outside EDF who are able to contribute in many ways.

Todd

#25 Re: Code_Aster usage » éléments finis de coque composites en thermoélasticité et grandes défo » 2011-03-05 01:01:38

AsterO'dactyle wrote:

We take care of all comments and every bug's report.

But the problem is there is no transparency! Every comment and bug reported simply disappears into a black hole.

How about this bug then? Submitted in December last year. http://www.code-aster.org/forum2/viewtopic.php?id=14683
I haven't heard anything more about it. Has it been assigned to anyone? Is anyone actively working on it? How would I know?

There is no road map for future developments. There is no facility to log requests for new features or see other user's requests. There is no opportunity to communicate with anyone who actually has knowledge in a particular area, because EDF manage the code-aster project behind an iron curtain.

So am I critical? Yes!

Todd.