Atom topic feed | site map | contact | login | Protection des données personnelles | Powered by FluxBB | réalisation artaban
You are not logged in.
Pages: 1
Dear Members,
we have a linear thermal simulation, where we would like to create heat transfer between surfaces of different parts, with a specified HTC.
We suppose, we should use the ECHANGE_PAROI option from AFFE_CHAR_THER. The model is fully 3D.
We get the following error message:
JDC.py : ERREUR A L'EXECUTION - INTERRUPTION
>> JDC.py : DEBUT RAPPORT
CR d'execution de JDC en MIXTE
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! <S> Exception utilisateur levee mais pas interceptee. !
! Les bases sont fermees. !
! Type de l'exception : error !
! !
! les deux listes &&CAECHP.LLIST1 et &&CAECHP.LLIST2 ne sont pas de mĂŞme !
! longueur !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fin CR d'execution de JDC en MIXTE
What can be the problem? We tried a lot of different things (LIAISON_MAIL worked), with different meshes on the connecting surfaces (face elements, and 3D elements, and combination of these, but we think that both group should be face element groups).
It worked on a small subset of these groups (a few face elements from both groups) , but on the whole groups, it never worked.
The model is attached (it is a small subset of the complate problem, and the numerical values are not the correct ones).
Thank you for your help.
BR.
dezsit
Last edited by dezsit (2017-09-28 15:37:28)
Offline
Due to the size limitation of attacments, I cannot upload the files.
It can be downloaded from the link, below:
http://mammutmail.com/hu/mail/download/ … 3c11938bf8
BR.
dezsit
Last edited by dezsit (2014-07-23 10:02:04)
Offline
Hi,
I did not have a look at your filed but your error might come from the fact that ECHANGE_PAROI requires both surface meshes to be compatible (that is with the same number of elements and able to be superposed with a geometric transformation).
What version are you using ? I'm pretty sure the error in current versions is much more user-friendly.
TdS
Offline
Hello,
thank you for your reply, that was our impression too. Finally we could handle the problem, with more detailed partitioning of the surfaces
involved into the heat exchange. The versions, what we tried, are the old stable (11.5) and latest testing (12.2).
It is planed in the future to make the handling of the surface pairs more user friendly? In complex assemblies, like
ours in this case, it is really a lot of time and effort to make the surface pairs identical. Additionaly it cause very distorted (and/or unnecessarily high amount) elements sometime.
It would be nice to implement some kind of tolerance (it would be good for the LIAISON_MAIL too, or any other commands, which are based on some kind of master-slave
pairing), which can handle the problem.
During the pairing phase (when slave nodes paired to master surface elements(?) nodes(?) ) if the slave node does not get any master pair from a
distance prescribed by a user defined tolerance, than the slave node excluded from the interaction.
(I'm pretty sure, that some kind of mechanism are already implemented, only the user is not able to overwrite it)
This tolereance could be calculted from the local element size (around the given slave node) by default.
The user could give an arbitrary large value, and the user's responsibility is, that this value (and pairing distance) has a physical meaning (or enough accuracy) or not.
The pre-processing of assemblies and complex geoemtries would be much faster with such a mechanism, for a global response model.
If the local, and more accurate behaviour is interested around the interaction, a submodel is prepared anyway, with more detailed geometry and mesh preparation.
Thank you,
BR.
dezsit
Offline
Dear Community,
I would like to rise up an old problem again, because I have not seen progress in it. (Or we missed something during the years?)
So my question is: Is it planed to handle the thermal contact (more precisely thermal resistance between walls - ECHANGE_PAROI) on based on a master-slave pairing approach? (I suppose the pairing algorithm of for example LIAISON_MAIL could be used easily in this case, which is already present in the AFFE_CHAR_THER operator). We could save a lot of partitioning/meshing work with that.
Thank you
and
Best regards,
DT.
Offline
Dear Community,
I would like to rise up an old problem again, because I have not seen progress in it. (Or we missed something during the years?)
So my question is: Is it planed to handle the thermal contact (more precisely thermal resistance between walls - ECHANGE_PAROI) on based on a master-slave pairing approach? (I suppose the pairing algorithm of for example LIAISON_MAIL could be used easily in this case, which is already present in the AFFE_CHAR_THER operator). We could save a lot of partitioning/meshing work with that.
Thank you
and
Best regards,
DT.
I joing with the same problem ... so if there are two of us probably it is more likely the development is made!
Offline
Dear Community,
I would like to rise up an old problem again, because I have not seen progress in it. (Or we missed something during the years?)
So my question is: Is it planed to handle the thermal contact (more precisely thermal resistance between walls - ECHANGE_PAROI) on based on a master-slave pairing approach? (I suppose the pairing algorithm of for example LIAISON_MAIL could be used easily in this case, which is already present in the AFFE_CHAR_THER operator). We could save a lot of partitioning/meshing work with that.
Thank you
and
Best regards,
DT.
Hi everybody,
are there any news about this topic? it would be really great to have a coupling between 2 non paired surfaces to define a thermal contact resistance. I remember something very easy in syrthes to define such contact thermal resistance between 2 surfaces.
thanks in advance,
Andrea
Offline
Pages: 1