Yes you are right. It turns out this is the problem.
I was creating a hyper_rectangle using grid generation class. Then 4 and 5
corresponded to the -/+ z surface.
(I used hard coded numbers as it saved time for looping over all the elements.)
>
> Now when I am using the same mesh but now reading via read_ucd(), upon reading
> the documentation carefully, I saw that the ordering is changed. So 4 and 5
> now no more correspond to -/+ z surface.
It's always a safe bet in debugging other people's codes to challenge their
underlying assumptions :-)
However, If I call cell->face(4)->unit_cell_direction, it still gives output
as 2, which means that this face is normal to z surface.
This normal direction is for the cell in the natural coordinates, right ?
In the "reference coordinate system" (which we often call the "unit cell
coordinate system". But that's not the coordinate system you care about.
So, in general, how should I know if the real cell face is normal to -/+ z
direction ?
You could query the z-coordinate of a face's center. Loop over all faces of a
cell, if you find one whose center's z-coordinate is at the top or bottom of
the domain, then you have a cell you care about.
Will having a constraint such that both the dofs are locally relevant & not
locally owned result in anything bad ? I think, it should have no effect
atleast for that processor on which both these two dofs lie.
Am I right here ?
Correct.
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
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.
