Continue to Site

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations The Obturator on being selected by the Eng-Tips community for having the most helpful posts in the forums last week. Way to Go!

Coupling of different DOFs using a specific set of formulations

Status
Not open for further replies.

Reza1989

Geotechnical
Jun 8, 2015
9
Hi everybody,


I've faced a problem for which I've not been able to find a solid answer; hence, it would be so nice of you if you could help me with it.

01) Is it possible to define the Force-Displacement relation of a spring using a UMAT (let's say I need a one directional displacement behavior, like a spring, which follows a user-defined constitutive relation)?

02) Let's imagine I have a single point the the bottom of my model, which has just 2 translational DOFs (namely in X and Y directions). Is there a way to define the relation of these two DOFs (which are coupled) via a complicated set of formulations?


I hope it is not vague.
Thank you very much in advance.
 
Replies continue below

Recommended for you

Dear Bartosz,

thanks a lot for your answer.
Well, the relation between the two DOFs that I mentioned, is in fact a coupling defined by a specific relatively complex failure surface which has to be defined in a separate file, so I don't think the *EQUATION works in this case.
I'll look forward to any other opinions :)

Best Regards,
Reza
 
a) I think uniaxial behavior for a connector element should do the job. You can provide tabulated coupled/uncoupled force-displacement values in various degrees of freedom.
b) MPC user subroutine is probably your best bet.

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Dear IceBreakerSours,


thank you very much for your reply. The MPC was something new for me actually, and I think it works! I need to spend some time on it and I'll update this "thread" with the result.

About your comment "a", I should say that I do not have a tabular data set, I need to implement the constitutive (material) law for the behavior in that DOF. Also a truss element would work, but just under the condition that I use a UMAT for it's material's behavior. Do you have any opinion?

thanks a lot :)


Best Regards,
Reza
 
You can write a script for the constitutive behavior, feed it a vector of fictitious displacements (say, -5.0 : 0.1 : 5.0) and generate your constitutive forces, can you not?

While they are fun and give you control, I try to avoid recommending user subroutines (unless there are no options) because just to get up and running with them can be a pain in the neck, let alone the actual FORTRAN coding (and the usual fun that comes with coding) for ABAQUS. Besides, many times, you can get away with some existing supported option.

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Despite the fact that I found your suggestion really interesting, I don't think I can use it since the behavior is not elastic, I mean for example, the loading and unloading path are different and I'm not sure if it can be used this way.

I know how tedious and troublesome a subroutine can be, but I'm afraid I don't have any other options since I'm dealing with a complete set of constitutive relations!

Thank you very much for your fruitful answers :)
 
I hope so, and I'll definitely get deeper in it to see if it is possible to feed the relationship in the connector using a subroutine.
Thank you very much for your support.
 
Connectors are among the most versatile elements. Assuming all you need to do is what you mentioned above, you do *NOT* need a subroutine. Let 'em go, man!

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
I highly appreciate your concern and kind guidance. I will definitely get deep in the Connectors to see if it works or not. Just to mention a bit more detail why I keep thinking of implementing a subroutine, I should say that I want to model the MacroElements which are used in Geotechnical engineering and have their own failure criteria and plastification rule :)
 
Ultimately, you may *have to* write a code; I just do not see a strong reason at this point given what you have specified so far (except the macro-elements that you have brought up; I am not sure about them). If you have folks around you who have written FORTRAN code for Abaqus, then you may be fine. Otherwise, be very careful! FYI: User subroutines are not supported by Abaqus.

Now, coming to your latest post: Damage can be modeled with connectors.

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Well, fortunately I will not deal with damage at least! But I have some clues how much writing a UEL could be tricky and troublesome!
I have not done it before, but to learn that, I have a good tutorial in PDF (which is easily found on the web) with examples, I think I'll start from that then.
Thank you very much for your support IceBreakerSours :)
 
If you have resources (months/years?, someone helpful who has coded elements before sitting next to your cubicle, etc. and blessing from supervisors/management - assuming they fully understand/appreciate what this might end up taking), then writing a UEL is an exciting venture. Have fun!

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Well, I'm pretty sure this is a quite complicated task, but you frightened me even more by that much insisting and mentioning the details! ;)
In fact, I have to do it, and I've got limited access to someone with the experience. Wish me luck then ;)
 
Coding a UMAT or a UEL isn't impossible; (depending on what you are trying to do) it can be hard for some of the best amongst us because resources are limited (time, support network, supervisor's blessing, money, ability, etc.) and that is what I was trying to emphasize. The intention was to make you aware of what you are getting into; not to scare you.

Like I said, coding subroutines is fun but, under constraints, it isn't a practical venture. I can tell you I *rarely* code any subroutines anymore because it is not pragmatic for me (for many reasons).

Since it isn't straightforward to tell the skillset/level of the person you are interacting with on a forum like this, one has to go by how they frame their question, the jargon they might use, etc. to get a feel for where they might stand at the time of asking the question vis-a-vis their destination. I frame my response accordingly.

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Thanks a lot for your guides and concern. You are totally right. Unfortunately I have to implement the specific MacroElements that I need for my thesis, despite my general awareness of the complexity of the task. I think I'll have a couple of month for the basic version of the formulations (which are not that complicated at least in theory) and limited access to some other resources like experienced people. I have to manage it somehow anyway.
Thank you very much again :)
 
Sure.

By the way, I am not sure what 'macroelements' are but, just in case, you meant to speak of 'superelements', you should know that Abaqus prefers to call them substructures. Check the documentation for more.

*********************************************************
Are you new to this forum? If so, please read these FAQs:

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor