Re: [deal.II] Accuracy of Dirichlet condition for p in step-20

[Wolfgang Bangerth]

Jane,

> Always setting local_rhs = 0 immediately before the below implementation 
> would take into account all cases so that would be the best:
> 
> for (unsigned int q=0; q for (unsigned int i=0; i local_rhs(i) += -(fe_face_values[velocities].value (i, q) *
> fe_face_values.normal_vector 
> (q)
>  
> *
> boundary_values[q] *
> fe_face_values.JxW 
> (q));

But it's already there, in the marked line (lkine 494 in the current 
sources):

 for (const auto  : dof_handler.active_cell_iterators())
   {
 fe_values.reinit(cell);
 local_matrix = 0;
 local_rhs= 0; // ***

 right_hand_side.value_list(fe_values.get_quadrature_points(),
rhs_values);
 k_inverse.value_list(fe_values.get_quadrature_points(),
  k_inverse_values);

 for (unsigned int q = 0; q < n_q_points; ++q)
   for (unsigned int i = 0; i < dofs_per_cell; ++i)
 ...cell integration...


 for (unsigned int face_n = 0;
  face_n < GeometryInfo::faces_per_cell;
  ++face_n)
   if (cell->at_boundary(face_n))
 {
   fe_face_values.reinit(cell, face_n);

   pressure_boundary_values.value_list(
 fe_face_values.get_quadrature_points(),
 boundary_values);

   for (unsigned int q = 0; q < n_face_q_points; ++q)
 for (unsigned int i = 0; i < dofs_per_cell; ++i)
   local_rhs(i) += ...

So all that is happening is that we accumulate contributions from all 
faces of the cell before we put it all into the global matrix. This is 
the right thing to do.


> As for the Stokes case, I am making the analogy for the INHOMOGENEOUS 
> normal component of normal stress boundary condition. \
> You are right in that the no tangential stress condition requires 
> nothing, but then i have a nonzero value of the normal component of the 
> normal stress which needs to be in the weak form.
> I can't quite figure out if this is a "dirichlet' condition so I also 
> set local_rhs = 0 before the boundary implementation, or whether it is 
> just an extra addition for the cells on that boundary.

It is correct that the normal component of the normal stress is nonzero. 
But it is multiplied by a test function whose normal component is zero 
(because the normal component of the solution is prescribed). So the 
product of these two terms is zero, and there is no additional 
contribution to the weak form.

Best
  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.

Re: [deal.II] Finding the y-coordinate of the boundary during the assembly

[Wolfgang Bangerth]

> Yes, what you put into much better words than mine is exactly what I am 
> needing - For a given quadrature point at
> (x,y), find how far the domain extends above (x,y) in y-direction?
> 
> So I am looking to find the y-coordinate of the point which is directly 
> above the (x,y) in question, so that I can find how far it extends above 
> it (by subtracting it from what I am trying to find)

As Jean-Paul already mentioned, this is easy enough if your top surface 
is level (i.e., at the same y value). It is, in general, difficult to 
figure this out on unstructured meshes if the top surface is not level.

The way to do this then is to define a "depth" variable D(x,y). You know 
that D(x,y)=0 at the top surface, and that it grows linearly with depth 
y. So D(x,y) satisfies a differential equation of the form

   d/d(-y) D(x,y) = 1

or equivalently

   d/dy D(x,y) = -1

which you can also write as follows:

  (0,-1) . nabla D(x,y) = 1

So it is an advection equation with the advection velocity being the 
vector pointing straight down. The boundary condition at the "inflow" 
boundary -- which here is the top boundary) is D(x,y)=0.

Then, if you need to know the depth at a given point (x_q,y_q), for 
example at a quadrature point when assembling your linear system, all 
you need to do is evaluate the depth field D(x_q,y_q) that you have 
previously computed.

Best
  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.

Re: [deal.II] Accuracy of Dirichlet condition for p in step-20

[jane . lee]

>What line of the code would that be? Do you think it would be wrong to 
just 
>*always* set local_rhs=0? 

Always setting local_rhs = 0 immediately before the below implementation 
would take into account all cases so that would be the best:

for (unsigned int q=0; qhttps://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#a130eea0fa89263d93b20521addc830c7>(q)
 
*
boundary_values[q] *
fe_face_values.JxW 

(q));

As for the Stokes case, I am making the analogy for the INHOMOGENEOUS 
normal component of normal stress boundary condition. \
You are right in that the no tangential stress condition requires nothing, 
but then i have a nonzero value of the normal component of the normal 
stress which needs to be in the weak form. 
I can't quite figure out if this is a "dirichlet' condition so I also set 
local_rhs = 0 before the boundary implementation, or whether it is just an 
extra addition for the cells on that boundary. 

On Friday, March 15, 2019 at 5:00:01 AM UTC, Wolfgang Bangerth wrote:
>
> On 3/14/19 5:02 PM, jane...@jandj-ltd.com  wrote: 
> > 
> > I think just a comment in the bit on how to implement the dirichlet bc 
> in the 
> > weak form would be sufficient - something to say 'In the case of an 
> > inhomogeneous boundary condition, you would need to set local_rhs = 0 
> before 
> > adding the cell contributions for the boundary condition'. 
>
> What line of the code would that be? Do you think it would be wrong to 
> just 
> *always* set local_rhs=0? 
>
>
> > I'm still unsure about the step-22 condition, for the normal component 
> for the 
> > normal stress. Is this equivalent to a dirichlet condition on the 
> pressure 
> > only? I'm a little confused on this one and any thoughts would be 
> helpful. 
>
> The normal stress shows up in the weak form after integrating by parts 
> both 
> the div(2*eta*eps(u)) and the grad p terms. The term is going to be 
> something like 
>(v, (2*eta*eps(u) - pI).n)_{Gamma} 
>
> So if you prescribe 
> * no normal flux 
> * no tangential stress 
> (i.e., "free slip"), then you will have: 
> * the normal component of v is zero 
> * the tangential component of (2*eta*eps(u) - pI).n is zero 
> As a consequence, the entire boundary term disappears, as you can see if 
> you 
> write the product of test function and normal stress as 
>(v, s.n) = (v_n, (s.n).n) + (v_t, (s.n) x n) 
> (normal component plus tangential component of vectors), where the first 
> of 
> the two terms on the right disappears because v_n=0 and the second because 
> (s.n) x n = 0. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@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.

[deal.II] New FiniteElement; Cohesive-zone model; A-FEM

[James Gorman]

To Whom It May Concern,

I am a graduate student who will be defending in the not-too-distant 
future, and afterwards I want to remain in the research community even 
though I will be leaving academia for the foreseeable future. My research 
group has an established cohesive-zone model (CZM) code that is used in 
Abaqus, and I have been using this for all of my graduate work. The main 
drawback to not switching over to deal.ii years ago was that it lacks the 
ability to model crack-propagation (which is the main focus of my 
research), and the resistance to changing from a code the group knows 
already works.

After I graduate, I want to move to completely (or nearly completely) 
open-source computation methods. deal.ii looks to be the best open-source 
FEM option, but using it will require me to write a new FiniteElement to 
implement the cohesive-zone model (as I still want to work on fracture 
mechanics). I have read some threads about the ability to use 
``zero-thickness'' cohesive/surface elements that have been used by others 
to model crack-propagation, but I think that is not the preferred method to 
deal with fracture.

With this in mind, would a user/developer be willing to guide me along the 
path of writing a new FiniteElement? I have already written initial 
traction-separation laws (in C++) that could be used in a "volume" 
cohesive-zone element. I have collected papers of others who have already 
written cohesive-zone finite-elements for the commercial software package 
Abaqus, and my intention would be to replicate this work (with perhaps some 
small modifications/improvements) for deal.ii so that I can continue work 
in fracture mechanics.

Additionally, does deal.ii have the capabilities of the so-called A-FEM 
(augmented finite element method)? A-FEM allows one element to change an 
element from one finite-element into another finite-element during the 
calculation. An example from fracture mechanics: starting with an initially 
isotropic elastic calculation of generic shape, when a certain stress 
threshold is met by an element, the elastic element is replaced with a CZM 
element to allow for arbitrary crack-initiation and propagation to occur. 
Note: other FEM-based methods appear to use this same idea of replacing one 
element type with another during a calculation, but I am do not have 
extensive knowledge of the nuanced differences between them.

Sincerely,
James Gorman

-- 
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.

Re: [deal.II] Finding the y-coordinate of the boundary during the assembly

[jane . lee]

Hi Jean Paul,

Thanks for this - for now this should be sufficient, though for the rest I 
will have to do a long blurb. 

Do you have an example of how to use BoundingBox? I'm a little confused by 
the document. I don't know what i have to set for the argument before i do 
something (i am guessing) like mydomain.get_boundary_points();

Thanks!


On Friday, March 15, 2019 at 11:30:36 AM UTC, Jean-Paul Pelteret wrote:
>
> Dear Jane,
>
> There is the BoundingBox 
>  class 
> that could tell you the overall extents of the domain. So if your geometry 
> is rectangular and not rotated then you could work out the difference 
> between the y-coordinate of the top vertex of the bounding box and your 
> point of interest. If you have an irregular domain then I think that you’re 
> going to have to work out the projection onto its upper surface yourself. I 
> don’t think that there’s any easy way to do this.
>
> I hope that this helps.
>
> Best,
> Jean-Paul
>
> On 15 Mar 2019, at 11:14, jane...@jandj-ltd.com  wrote:
>
> Hi Wolfgang,
>
> Yes, what you put into much better words than mine is exactly what I am 
> needing - For a given quadrature point at 
> (x,y), find how far the domain extends above (x,y) in y-direction?
>
> So I am looking to find the y-coordinate of the point which is directly 
> above the (x,y) in question, so that I can find how far it extends above it 
> (by subtracting it from what I am trying to find)
>
> On Friday, March 15, 2019 at 5:03:56 AM UTC, Wolfgang Bangerth wrote:
>>
>> On 3/14/19 5:50 PM, jane...@jandj-ltd.com wrote: 
>> > 
>> > I've tried looking a cell->face(face_no)->at_boundary() type input 
>> within the 
>> > cell iterator and by using something like cell->vertex(v)(1) but I 
>> can't quite 
>> > get my head around how to find the y coordinate of the top boundary for 
>> every 
>> > cell/quadrature point calculation. 
>>
>> Jane, 
>> if you've already identified that a face is at the boundary, then 
>>cell->face(face_no)->center() 
>> returns a Point object. So if you need the y-coordinate, it would be 
>>cell->face(face_no)->center()[1] 
>>
>> Or are you asking the following question: "For a given quadrature point 
>> at 
>> (x,y), find how far the domain extends above (x,y) in y-direction"? 
>>
>> Best 
>>   W. 
>>
>> -- 
>>  
>> Wolfgang Bangerth  email: bang...@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+un...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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.

Re: [deal.II] Interfacing deal.ii for solution, pre and post-processing

[Muhammad Mashhood]

Thank you Jean! That was a very comprehensive summary for me to take 
initial steps and motivation for deal.ii. The main concern from me however 
remains now for the reading and dealing with boundary conditions I am 
interested in my solid mechanics case simulations. If there are some 
external, high end or specialized interfaces present for them too to 
control what has to happen inside of the the BC interpolation functions 
with named boundary ids that would make a lot more ease.   

On Friday, March 15, 2019 at 4:40:43 PM UTC+1, Jean-Paul Pelteret wrote:
>
> Dear Muhammad,
>
> You can look at the documentation to the GridIn 
>  namespace 
> for some ideas as to which software supports the generation of mesh files 
> that deal.II can read, and the and GridOut 
>  namespace 
> for the types of output deal.II can make and some programs that can read 
> them in. 
>
> I think that it depends greatly on what you’re trying to accomplish as to 
> what software you may consider using. For example, I often simulate 
> problems that require intricate geometry and, therefore, an intricate mesh. 
> So I use a commercial tool like Cubit to create the mesh and post-process 
> results using Paraview. I would say that GMSH and Salome are two other 
> preprocessors that would be commonly used (but neither of which I have much 
> familiarity with). Of course, deal.II has itself got some basic mesh 
> generation capabilities that may be perfectly suitable for you. Another 
> often-used post-processor is Visit. 
>
> The application of boundary conditions is done differently to how one much 
> setup BCs in a mesh that is then read into, say, ABAQUS. With deal.II you 
> may only specify an identifying number (known as a boundary_id) to the 
> boundaries, which you then interpolate some boundary condition function 
> onto. I know thats some commercial software interprets physical boundary 
> conditions directly from the mesh itself but, since deal.II is a finite 
> element library and not a multi physics library, it would have no 
> understanding of what these types of boundary conditions mean.
>
> Does that help you?
>
> Best,
> Jean-Paul
>
> On 15 Mar 2019, at 16:18, Muhammad Mashhood  > wrote:
>
> Dear all,
> I am new to deal.ii and looking for a nice interfacing tool 
> for making mesh import, BC application, solution and post-processing for 
> simulation cases etc. easy for me. Can anyone give me suggestion regarding 
> this? Thank you!
>
>
>
> -- 
> 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+un...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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.

Re: [deal.II] Interfacing deal.ii for solution, pre and post-processing

[Jean-Paul Pelteret]

Dear Muhammad,

You can look at the documentation to the GridIn 
 namespace for 
some ideas as to which software supports the generation of mesh files that 
deal.II can read, and the and GridOut 
 namespace for 
the types of output deal.II can make and some programs that can read them in. 

I think that it depends greatly on what you’re trying to accomplish as to what 
software you may consider using. For example, I often simulate problems that 
require intricate geometry and, therefore, an intricate mesh. So I use a 
commercial tool like Cubit to create the mesh and post-process results using 
Paraview. I would say that GMSH and Salome are two other preprocessors that 
would be commonly used (but neither of which I have much familiarity with). Of 
course, deal.II has itself got some basic mesh generation capabilities that may 
be perfectly suitable for you. Another often-used post-processor is Visit. 

The application of boundary conditions is done differently to how one much 
setup BCs in a mesh that is then read into, say, ABAQUS. With deal.II you may 
only specify an identifying number (known as a boundary_id) to the boundaries, 
which you then interpolate some boundary condition function onto. I know thats 
some commercial software interprets physical boundary conditions directly from 
the mesh itself but, since deal.II is a finite element library and not a multi 
physics library, it would have no understanding of what these types of boundary 
conditions mean.

Does that help you?

Best,
Jean-Paul

> On 15 Mar 2019, at 16:18, Muhammad Mashhood  wrote:
> 
> Dear all,
> I am new to deal.ii and looking for a nice interfacing tool for 
> making mesh import, BC application, solution and post-processing for 
> simulation cases etc. easy for me. Can anyone give me suggestion regarding 
> this? Thank you!
> 
> 
> 
> -- 
> 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 
> .

-- 
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.

[deal.II] Interfacing deal.ii for solution, pre and post-processing

[Muhammad Mashhood]

Dear all,
I am new to deal.ii and looking for a nice interfacing tool for 
making mesh import, BC application, solution and post-processing for 
simulation cases etc. easy for me. Can anyone give me suggestion regarding 
this? Thank you!


-- 
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.

Re: [deal.II] issues with manifold id (at least in codim-1) revealed by PR 7775

[Nicola Giuliani]

I agree that the choice is ambiguous on the faces. 

However a practical problem remains, let's assume that a user wants to 
import a very big geometry with a lot of internal faces. Right now he would 
need to specify all the possible faces in the input file (with an 
increasing possibility of confusing the manifold ids). 
I agree he should (otherwise is a criminal) specify what happens when two 
different manifolds meet but if we have a face neighbouring two cells with 
the same manifold_id couldn't (or shouldn't) we assume the manifold of the 
face to be the same? 
Alternatively we could write a utility to transfer the manifold information 
to the faces, it should be "morally" the same of calling 
set_all_manifold_ids.

Il giorno mercoledì 13 marzo 2019 08:32:31 UTC+1, Luca Heltai ha scritto:
>
> I believe the first point is a bug of the read_ucd function. 
>
> I opened an issue for this (https://github.com/dealii/dealii/issues/7802) 
>
> The second point, however, is a feature. What should you do when two 
> material ids meet? I think it is the responsability of the user to make 
> sure that the correct manifold id is associated to the correct face. 
>
> Currently our read/write vtk functions (in the GridIn class) are the only 
> ones allowing full treatment  material ids, boundary ids, and manifold ids. 
>
> I’m not sure UCD format allows you to specify both material and manifold 
> ids for cells, and boundary and manifold is for faces. Maybe Andrea knows 
> better? 
>
> L. 
>
> > On 8 Mar 2019, at 15:15, Nicola Giuliani  > wrote: 
> > 
> > PR 7775 has revealed some critical issues in the handling of manifold_id 
> in codim-1 domain. 
> > 
> > -) I believe that GridIn.read_ucd appears to ignore manifold ids 
> associated to the cells, it seems to me that the flag 
> apply_all_indicators_to_manifold_ids does not affect the manifold id for 
> the cell. This issue has never been seen because internally the material_id 
> was used. 
> > 
> > -) As far as I understand the default behaviour is to consider only user 
> specified manifold ids for the lines of a cell otherwise flat_manifold_id. 
> Would it make sense to use the cell->manifold_id instead of 
> flat_manifold_id? 
> > 
>
>

-- 
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.

Re: [deal.II] Finding the y-coordinate of the boundary during the assembly

[Jean-Paul Pelteret]

Dear Jane,

There is the BoundingBox 
 class 
that could tell you the overall extents of the domain. So if your geometry is 
rectangular and not rotated then you could work out the difference between the 
y-coordinate of the top vertex of the bounding box and your point of interest. 
If you have an irregular domain then I think that you’re going to have to work 
out the projection onto its upper surface yourself. I don’t think that there’s 
any easy way to do this.

I hope that this helps.

Best,
Jean-Paul

> On 15 Mar 2019, at 11:14, jane@jandj-ltd.com wrote:
> 
> Hi Wolfgang,
> 
> Yes, what you put into much better words than mine is exactly what I am 
> needing - For a given quadrature point at 
> (x,y), find how far the domain extends above (x,y) in y-direction?
> 
> So I am looking to find the y-coordinate of the point which is directly above 
> the (x,y) in question, so that I can find how far it extends above it (by 
> subtracting it from what I am trying to find)
> 
> On Friday, March 15, 2019 at 5:03:56 AM UTC, Wolfgang Bangerth wrote:
> On 3/14/19 5:50 PM, jane...@jandj-ltd.com  wrote: 
> > 
> > I've tried looking a cell->face(face_no)->at_boundary() type input within 
> > the 
> > cell iterator and by using something like cell->vertex(v)(1) but I can't 
> > quite 
> > get my head around how to find the y coordinate of the top boundary for 
> > every 
> > cell/quadrature point calculation. 
> 
> Jane, 
> if you've already identified that a face is at the boundary, then 
>cell->face(face_no)->center() 
> returns a Point object. So if you need the y-coordinate, it would be 
>cell->face(face_no)->center()[1] 
> 
> Or are you asking the following question: "For a given quadrature point at 
> (x,y), find how far the domain extends above (x,y) in y-direction"? 
> 
> Best 
>   W. 
> 
> -- 
>  
> Wolfgang Bangerth  email: bang...@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 
> .

-- 
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.

Re: [deal.II] Finding the y-coordinate of the boundary during the assembly

[jane . lee]

Hi Wolfgang,

Yes, what you put into much better words than mine is exactly what I am 
needing - For a given quadrature point at 
(x,y), find how far the domain extends above (x,y) in y-direction?

So I am looking to find the y-coordinate of the point which is directly 
above the (x,y) in question, so that I can find how far it extends above it 
(by subtracting it from what I am trying to find)

On Friday, March 15, 2019 at 5:03:56 AM UTC, Wolfgang Bangerth wrote:
>
> On 3/14/19 5:50 PM, jane...@jandj-ltd.com  wrote: 
> > 
> > I've tried looking a cell->face(face_no)->at_boundary() type input 
> within the 
> > cell iterator and by using something like cell->vertex(v)(1) but I can't 
> quite 
> > get my head around how to find the y coordinate of the top boundary for 
> every 
> > cell/quadrature point calculation. 
>
> Jane, 
> if you've already identified that a face is at the boundary, then 
>cell->face(face_no)->center() 
> returns a Point object. So if you need the y-coordinate, it would be 
>cell->face(face_no)->center()[1] 
>
> Or are you asking the following question: "For a given quadrature point at 
> (x,y), find how far the domain extends above (x,y) in y-direction"? 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@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.