Using mesh created in Cubit

[Alex C.]

Hello,

I'm part of a research group attempting to model fluid flow in the anterior chamber of the eye. We are attempting to import a mesh generated in Cubit along with the boundary conditions, but when we convert the .inp file to a .ucd file using the mesh converter, we get a segmentation fault. The mesh converter seems to be working when the .inp file contains information for just the surface of the mesh. It breaks when we add boundary conditions. Is it possible to import a mesh with boundary conditions from Cubit, or will we have to set the boundary conditions using deal.II? If so, how would we go about this? Sorry if some of these questions have obvious answers. We are still in the process of learning about these pieces of software.     

[Krzysztof Bzowski]

Hi,
As far as I know, you can import only boundary ids.
It means that deal.ii will recognize external faces but implementation
of boundary conditions are up to you.

Can you share your mesh? Would be simpler to check the problem.

Best regards,
Krzysztof

[Alex C.]

Attached is the mesh. Whenever we use the mesh_converter, we get:

WARNING: expected SURFACE after ELSET.

WARNING: expected SURFACE after ELSET.

Segmentation fault (core dumped)

Thank you.

[Krzysztof Bzowski]

On date 2014-07-08 15:07, Alex C. wrote:
> Attached is the mesh. Whenever we use the mesh_converter, we get:
>
> WARNING: expected SURFACE after ELSET.
> WARNING: expected SURFACE after ELSET.
> Segmentation fault (core dumped)

Are you sure, that everything was exported correctly?
I am asking because nodes numeration in your file starts from 382 and
elements from 297 which is a little bit strange.

MeshConverter assumes that numeration of elements and nodes start from 1
- this cause the problems.

Mesh looks like: http://imgur.com/2MGletQ
Is this what you wanted?

[Alex C.]

That is the correct mesh. It is possible that it did not export correctly, although I'm not certain as to why that would happen. 

[Krzysztof Bzowski]

I wrote small patch which fix that issue. Check attached file.
If everything is alright I'll post it on the bugtracker.

Best regards,
K.

[Alex C.]

Thank you! That is something along the lines of what we were expecting to see when we ran the mesh_conversion the first time. When I attempted to run the program, I got the following error message:

An error occurred in line <1830> of file </home/alexcope/deal.II/source/grid/tria.cc> in function

    static void dealii::internal::Triangulation::Implementation::create_triangulation(const std::vector<dealii::Point<dim, double> >&, const std::vector<dealii::CellData<2> >&, const dealii::SubCellData&, dealii::Triangulation<2, spacedim>&) [with int spacedim = 2]

The violated condition was: 

    ! (line->boundary_indicator() != 0 && line->boundary_indicator() != numbers::internal_face_boundary_id)

The name and call sequence of the exception was:

    ExcMultiplySetLineInfoOfLine(line_vertices.first, line_vertices.second)

Additional Information: 

In SubCellData the line info of the line with vertex indices 44 and 43 is multiply set.

--------------------------------------------------------

Aborting!

----------------------------------------------------

make[3]: *** [CMakeFiles/run] Error 1

make[2]: *** [CMakeFiles/run.dir/all] Error 2

make[1]: *** [CMakeFiles/run.dir/rule] Error 2

make: *** [run] Error 2

FYI, we are attempting to run this mesh with modified conditions in the tutorial program, step-35.cc. I don't know if that helps you any or not.  

[Ross Kynch]

Hi Alex,

I've recently been using cubit to create meshes and found that converting to ucd in cubit rather than using the mesh converter seemed to work well. I've not considered particularly complex geometries but I have been able to apply boundary IDs as material IDs. I am still testing my code but as far as I can tell, the mesh does import correctly this way.

Ross

[Krzysztof Bzowski]

On date 2014-07-08 17:05, Alex C. wrote:
> Thank you! That is something along the lines of what we were expecting
> to see when we ran the mesh_conversion the first time. When I attempted
> to run the program, I got the following error message:

I will try to debug the problem. Meanwhile Ross solution is reasonable
alternative.

Best regards,
K.

[Alex C.]

Okay, so I think I have established boundary indicators using the following code:

    for (typename Triangulation<dim>::active_cell_iterator cell = triangulation. begin_active(); cell != triangulation.end(); ++cell)

      {

      for (unsigned int f=0; f<GeometryInfo<dim>::faces_per_cell; ++f)

    {

     if (cell->face(f)->at_boundary())

       {

         if (cell->face(f)->center()[0] == 4)

    {

     cell->face(f)->set_boundary_indicator (1);

    }

         else if (cell->face(f)->center()[0] == 5 && (cell->face(f)->center()[1]>5.5 || cell->face(f)->center()[1]<-5.5))

    {

     cell->face(f)->set_boundary_indicator (2);

    }

       }

    }

      }

Boundary 1 indicates the inlet for flow and Boundary 2 indicates the outlet regions. Everything else is treated as Boundary 0 and I want that to have a no-clip condition. I want to set the inlet flow velocity to 1.2 mm/s and the outlet pressure 1200 Pa. I don't quite understand how the boundary and initial conditions are implemented in the Navier-Stokes problem (step 35). Any advice? If I understand that problem a little bit better, I think I can correctly implement my own boundary conditions.  

[Alex C.]

Never mind, I got it working. Thanks for all of the help!

[Wolfgang Bangerth]

On 07/08/2014 09:46 AM, Krzysztof Bzowski wrote:
> I wrote small patch which fix that issue. Check attached file.
> If everything is alright I'll post it on the bugtracker.

Krysztof -- since your patch seems to be strictly progress, can you post it so
we can include it?

In general, the mesh converted was written with very specific .inp files in
mind and probably makes a good number of assumptions that not every .inp file
satisfies. If anyone has ideas on how to make it more robust (either by
letting it ignore/warn about parts it doesn't know how to deal with, or by
implementing handling these parts), we'll be happy to accept any patch that
makes even small progress.

Best
W.

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