Strange error in 9.0.0-pre version: the size of two component support points is not twice the single component support points

[Sambit Das]

Hello deal-ii team,

When I compare the sizes of the support points extracted using DoFTools::map_dofs_to_support_points(..) for two different DofHandlers- one for single component fields and another for two component fields, I get the following erroneous result: 

New pre-release version (9.0.0-pre) 

Size of one component support points in processor id :1 , 285

 Size of two component support points in processor id :1 , 569

Older version deal ii (dealii-8.5.1)

 Size of one component support points in processor id :1 , 480

 Size of two component support points in processor id :1 , 960

It is clearly observed that the size of the two component support points in the 9.0.0-pre version is not twice the size of the one component support points.

The above issue is only happening if all the underlying things are true:

1) mesh is being read gridin.read_ucd(..), I have attached the corresponding mesh file as mesh.inp. It is a uniform mesh of 1000 elements and size (7.6x7.6x7.6) generated using CUBIT.  When I use dealii's in house mesh generation the above issue doesn't occur.

2) periodic boundary conditions

3) parallel (I specifically ran the minimal example on 16 processors)

Note: The minimal example reads the file "mesh.inp"

Thanks,

Sambit

[Sambit Das]

Just to add to my above post when I ran in debug mode I get the following error

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

An error occurred in line <3873> of file </home/vikramg/DFT-FE-softwares/softwareCentos/dealii-patched/dealii/source/dofs/dof_handler_policy.cc> in function

    dealii::internal::DoFHandler::NumberCache dealii::internal::DoFHandler::Policy::ParallelDistributed<DoFHandlerType>::distribute_dofs() const [with DoFHandlerType = dealii::DoFHandler<3, 3>]

The violated condition was: 

    cell->user_flag_set() == false

Additional information: 

    This exception -- which is used in many places in the library -- usually indicates that some condition which the author of the code thought must be satisfied at a certain point in an algorithm, is not fulfilled. An example would be that the first part of an algorithm sorts elements of an array in ascending order, and a second part of the algorithm later encounters an element that is not larger than the previous one.

There is usually not very much you can do if you encounter such an exception since it indicates an error in deal.II, not in your own program. Try to come up with the smallest possible program that still demonstrates the error and contact the deal.II mailing lists with it to obtain help.

Stacktrace:

-----------

#0  /home/vikramg/DFT-FE-softwares/softwareCentos/dealii-patched/install_intel_17.0.1_bugfix1/lib/libdeal_II.g.so.9.0.0-pre: dealii::internal::DoFHandler::Policy::ParallelDistributed<dealii::DoFHandler<3, 3> >::distribute_dofs() const

#1  /home/vikramg/DFT-FE-softwares/softwareCentos/dealii-patched/install_intel_17.0.1_bugfix1/lib/libdeal_II.g.so.9.0.0-pre: dealii::DoFHandler<3, 3>::distribute_dofs(dealii::FiniteElement<3, 3> const&)

#2  ./minimalExampleBugReproduceNewVersionReadMesh: main

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

Calling MPI_Abort now.

To break execution in a GDB session, execute 'break MPI_Abort' before running. You can also put the following into your ~/.gdbinit:

  set breakpoint pending on

  break MPI_Abort

  set breakpoint pending auto

[Wolfgang Bangerth]

On 12/16/2017 06:40 PM, Sambit Das wrote:
> Just to add to my above post when I ran in debug mode I get the following error

Everything that happens after this error can definitely not be relied upon any
more. So I'm not surprised that the information you get is not correct.

Can you create a github issue with the minimal testcase that reproduces this
error (and remove any code that would run after the call to distribute_dofs
that triggers this)?

Once that is fixed, we can go back to the original issue and see whether that
is fixed as well.

Thanks
W.

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

[Sambit Das]

Hello Prof. Bangerth,

Thank you for your reply. I have trimmed the minimal example to just reproduce the error in the debug mode and created a github issue.

Thanks,

Sambit