Reading Abaqus boundary conditions

[Jie Cheng]

Hi all

Recently I started to reconstruct my old hand-written finite element code with deal.II. Although deal.ii offers a lot of useful functionalities that make my life much easier, there is one thing I find inconvenient and not sure what to do.

I'd like to read the mesh file from Abaqus, which can be done with GridIn::read_abaqus. But it seems unable to process the boundary conditions (Dirichlet bc such as displacement) and loads (Neumann bc such as traction, pressure). The way abaqus uses to express boundary conditions is as following:

*Nset, nset=fix-xy, generate

   1,  133,   33

*Elset, elset=fix-xy, generate

  1,  97,  32

... ...

** Name: BC-1 Type: Displacement/Rotation

*Boundary

Part-1-1.fix-xy, 1, 1

Part-1-1.fix-xy, 2, 2

Basically it marks the node and element ids on which the bc is defined.

And the way abaqus deals with loads is:

*Elset, elset=_top_S3, internal, generate

  97,  128,    1

*Surface, type=ELEMENT, name=top

_top_S3, S3

... ...

** LOADS

** 

** Name: Load-1   Type: Surface traction

*Dsload, constant resultant=YES

Part-1-1.top, TRVEC, 10., 0., -1., 0.

** 

It writes down the element ids and face ids of the faces that we are interested in.

As you can see, both are dependent on the mesh, rather than the geometry. Is there a way to import this information to deal.II? More specifically, I want to generate a map of global_dof_index to boundary values for the boundary conditions, and a non-zero boundary id for the element faces subjected to load.

Thank you

Jie

[Jean-Paul Pelteret]

Hi Jie,

Unfortunately this is not possible to do in our current implementation. The format of an Abaqus mesh file is quite general, and suggested by the documentation our parser has only the capability to read in a file with a very specific format. At this point in the source code you can see what the parser expects for materials and here for surfaces (boundaries). It would be unreasonable to allow any string entries ("names"): since we store our boundary ID's as integers, what would be the correlation between the name you give a surface and the generated boundary id? Furthermore, deal.II doesn't know anything about the physics of your problem, so that your boundary condition represents a constant traction or anything else would, again, be impossible to interpret in general (we would have to generate boundary Functions to match the input data). Abaqus and other FEM packages might be able to read in such a mesh, but in all likelihood they themselves would also have some limitations in terms of the input file format. 

its quite possible that with a mesh of this structure we would simply ignore all of these sections; however, it may also trigger an assertion. What you could do is split/parse the mesh into two parts, with the first being read by read_abaqus() to generate the grid without boundary ID's and the second being something that you parse yourself in order to interpret your specific boundary conditions. I don't think that this would necessarily be trivial to do, because you would have to work out (or duplicate from our source code) the element rotations on each face, etc.  Alternatively, you could just recreate your mesh files with surface ID's (or sidesets, as Cubit calls them) that are compatible with this function. You'd then have to interpret the meaning of each boundary on a case-by-case basis for each mesh.

I hope that this explains in sufficient detail why our mesh reader is as limited as it is.

Regards,

Jean-Paul

[Jie Cheng]

Hi Jean-Paul

Thanks for your answer. Now I understand that the problem was deal.II is expecting an integer as the surface name so that it can be converted to boundary id. So I changed my surface name from "top" to "1" (without quotes). But all the faces that are at the boundary still have the boundary id = 0. The method that I used to check the boundary id is cell->face(face)->boundary_id(). 

I expected some boundary ids to be 1. But deal.II was able to figure out how many faces are at the boundary. What did I miss?  Do you have a sample Abaqus file that deal.II can process (read mesh and boundary IDs)?

Thanks

Jie

[Wolfgang Bangerth]

On 08/17/2017 07:35 PM, Jie Cheng wrote:
>
> Thanks for your answer. Now I understand that the problem was deal.II is
> expecting an integer as the surface name so that it can be converted to
> boundary id. So I changed my surface name from "top" to "1" (without quotes).
> But all the faces that are at the boundary still have the boundary id = 0. The
> method that I used to check the boundary id is cell->face(face)->boundary_id().

That should be the way to do it. I don't know whether our Abaqus reader
actually reads boundary values, though. You may have to take a look at the
source code.

> I expected some boundary ids to be 1. But deal.II was able to figure out how
> many faces are at the boundary. What did I miss? Do you have a sample Abaqus
> file that deal.II can process (read mesh and boundary IDs)?

Take a look at the ones here:
https://github.com/dealii/dealii/tree/master/tests/grid/grids/abaqus

Best
W.


--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Jean-Paul Pelteret]

Hi Jie,

 

That should be the way to do it. I don't know whether our Abaqus reader
actually reads boundary values, though. You may have to take a look at the
source code.

Yes it does, but the boundary ID's must be prefixed. It looks like you have to name the surfaces

SS<boundary indicator>

or

SURF-<indicator> 

As Wolfgang suggested, there are a number of examples of grids in the test suite that you can examine. That should help you duplicate the expected format!

Regards,

Jean-Paul 

[Jie Cheng]

Hi Jean-Paul and Wolfgang

Following your suggestions, I found that  the name of surfaces must be prefixed with SS, for example SS1. The SURF- prefix doesn't work. Now my program can apply boundary indicators to the target surfaces. I will write code to read the traction/pressure load and apply them to the right boundary.

Before I close this thread, a simply question on the displacement (or Dirichlet in general) boundary conditions: Abaqus apply them directly to the nodes (more specifically dofs), while in deal.II, the displacement bc must be defined on a surface, because the map from global_dof_index to boundary_values must be constructed with VectorTools::interpolate_boundary_values which requires a boundary_id. Does this mean I should define a surface in Abaqus to indicate where I want to apply displacement bc?

Thank you very much!

Jie

[Jean-Paul Pelteret]

Dear Jie,

Great, I'm glad that you've managed to read in a grid with boundary indicators!

Does this mean I should define a surface in Abaqus to indicate where I want to apply displacement bc?

I would presume so. This is how it must be done when using Cubit, and I would suspect that the same must apply to Abaqus.

Regards,

Jean-Paul