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 On Thursday, August 17, 2017 at 7:13:33 PM UTC-4, Jean-Paul Pelteret wrote: > > 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 > <https://www.dealii.org/8.5.0/doxygen/deal.II/classGridIn.html#a51f7977b217e305d3538574cbd3d3a01> > our > parser has only the capability to read in a file with a very specific > format. At this point > <https://github.com/dealii/dealii/blob/master/source/grid/grid_in.cc?utf8=%E2%9C%93#L3031> > > in the source code you can see what the parser expects for materials and > here > <https://github.com/dealii/dealii/blob/master/source/grid/grid_in.cc?utf8=%E2%9C%93#L3077> > > 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 > > On Thursday, August 17, 2017 at 8:31:07 PM UTC+2, Jie Cheng wrote: >> >> 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 >> >> >> >> -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
