[deal.II] Re: Step-9, iterator over the cell

[Bruno Turcksin]

Jaekwong

On Thursday, August 24, 2017 at 5:01:24 PM UTC-4, Jaekwang Kim wrote:
>
>
> 
>
>
> *case 1: *
> when we iterate over on cell-4 in my pic, it has four faces and each face 
> has its neighbor, (2,3,5,6) 
>
> for cell, 2 and 3, it has same refinement level and I assume that 2 and 3 
> become automatically active. 
>
> and I wonder what happens when it comes to 5 and 6. where the neighbor 
> cell has one coarse level? 
>
There is no problem, you will get 5 and 6.
 

> *case 2: *
>
> when we iterative over on cell-5 in my pic, I am assuming that the cell 
> 2,4 and 7 are automatically activated neighbor cell... 
>
> and we don't need to anything special.. 
>
No, you do. You won't get cell 2 or 4. Take a look here 

 
and here The sentence you highlighted is for case 2 not case 1. 



Best, 



Bruno


-- 
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] Step-9, iterator over the cell

[Jaekwang Kim]

Hi, all. 
I have a questions on an algorithm in step-9 that does some iteration over 
the cell with its neighbors. 

I tried to read explanation carefully, but some part is unclear yet. 

In step-9, one class estimates a gradient of solution in each cell by 
calculating estimated value from its neighbor cells. 

Special care might be needed when our domain consist of different level of 
refinement in order to include all neighbor cells, and I think this parts 
from step-9 does this... but I am not understanding this.. 

I made some example, in the simple mesh above, 


*case 1: *
when we iterate over on cell-4 in my pic, it has four faces and each face 
has its neighbor, (2,3,5,6) 

for cell, 2 and 3, it has same refinement level and I assume that 2 and 3 
become automatically active. 

and I wonder what happens when it comes to 5 and 6. where the neighbor cell 
has one coarse level? 

The explanation in step 9 tutorial tells us that.. 

*If we are not in 1d, we collect all neighbor children `behind' the 
subfaces of the current face*
for (unsigned int subface_no=0; subface_non_children(); ++subface_no)
active_neighbors.push_back (
std::get<0>(*cell)->neighbor_child_on_subface(face_no,subface_no));
}
}


and I think I don't understand the blue line properlyand especially the 
word subfaces means.

*case 2: *

when we iterative over on cell-5 in my pic, I am assuming that the cell 2,4 
and 7 are automatically activated neighbor cell... 

and we don't need to anything special.. 

I would appreciate if someone can help me. 

Thanks!!


Jaekwang 



 

template 

void

GradientEstimation::estimate_cell (const 
SynchronousIterators > ,

   EstimateScratchData 
  _data,

   const EstimateCopyData &)

{

Tensor<2,dim> Y;



std::vector::active_cell_iterator> 
active_neighbors;

active_neighbors.reserve (GeometryInfo::faces_per_cell *

  GeometryInfo::max_children_per_face);



typename DoFHandler::active_cell_iterator 
cell_it(std_cxx11::get<0>(cell.iterators));





scratch_data.fe_midpoint_value.reinit (cell_it);



Tensor<1,dim> projected_gradient;



active_neighbors.clear ();



for (unsigned int face_no=0; 
face_no(cell.iterators)->at_boundary(face_no))

{



//just definition of abbreviation for the iterator to the 
face and the neighbor...

const typename DoFHandler::face_iterator

face = std_cxx11::get<0>(cell.iterators)->face(face_no);

const typename DoFHandler::cell_iterator

neighbor = std_cxx11::get<0
>(cell.iterators)->neighbor(face_no);





if (neighbor->active())

active_neighbors.push_back (neighbor);  //increase 
storage

else

{

// neighbor cell can be one level of coasered

// You should find all neighbor cell



// find a child of neighbor



if (dim == 1)  // special care is necessary for 1D case

{  



typename DoFHandler::cell_iterator 
neighbor_child = neighbor;

while (neighbor_child->has_children())

neighbor_child = neighbor_child->child 
(face_no==0 ? 1 : 0);



Assert (neighbor_child->neighbor(face_no==0 ? 1 : 0)

==std_cxx11::get<0
>(cell.iterators),ExcInternalError());



active_neighbors.push_back (neighbor_child);

}

else  // Most cases will fall under this case (2D and 
3D Problems..)

for (unsigned int subface_no=0; subface_no < 
face->n_children(); ++subface_no)

active_neighbors.push_back (std_cxx11::get<0
>(cell.iterators)->neighbor_child_on_subface(face_no,subface_no));

}

}



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

Re: [deal.II] Using deal.II logo in publication

[Wolfgang Bangerth]

On 08/24/2017 01:38 PM, Timo Heister wrote:

What about putting the logo and a download link to a high resolution
variant on the homepage ont the Info -> License page [1]?

That would be great. I also don't think we have a high-resolution
(ideally vector art) version yet.


Yes, all that sounds good to me, but I don't have anything higher than
   http://dealii.org/pictures/hugelogo.jpg
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] Using deal.II logo in publication

[Matthias Maier]

What about putting the logo and a download link to a high resolution
variant on the homepage ont the Info -> License page [1]?

Stating something like

  deal.II Logo
  

  The deal.II logo is copyrighted by ... and can be used under a [CC BY 4.0
  license](link to license). You can find a high-resolution version
  [here](link to logo).


Best,
Matthias

[1] http://dealii.org/license.html

-- 
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] Re: Output nodal scalar

[Jie Cheng]

Thank you Jean-Paul. I did not hear about L2-projection method before, but 
it seems that the L2-projection method also evaluates the stress tensor at 
the quadrature points and then finds the cell-averaged stress. The only 
difference compared with the heuristic method is that it solves AX = Y 
where A is mass matrix, Y is integration of cell-averaged stress component 
and X is the nodal stress component that we want. Is that right?

On Thursday, August 24, 2017 at 12:37:33 PM UTC-4, Jean-Paul Pelteret wrote:
>
> There's also the MeshWorker 
> 
>  
> framework which has some integrators that can help. But I don't know how 
> that works so I can't help you further other than to point it out to you.
>
> On Thursday, August 24, 2017 at 6:35:18 PM UTC+2, Jean-Paul Pelteret wrote:
>>
>> I can't think of any off of the top of my head, but I think that 
>> MatrixCreator::create_mass_matrix() 
>> 
>>  plus 
>> VectorTools::create_right_hand_side() 
>> 
>>  
>> collectively assemble what you're wanting. Its really not difficult to do 
>> by hand - you should just give it a go!
>>
>

-- 
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] Re: Output nodal scalar

[Jean-Paul Pelteret]

There's also the MeshWorker 

 
framework which has some integrators that can help. But I don't know how 
that works so I can't help you further other than to point it out to you.

On Thursday, August 24, 2017 at 6:35:18 PM UTC+2, Jean-Paul Pelteret wrote:
>
> I can't think of any off of the top of my head, but I think that 
> MatrixCreator::create_mass_matrix() 
> 
>  plus 
> VectorTools::create_right_hand_side() 
> 
>  
> collectively assemble what you're wanting. Its really not difficult to do 
> by hand - you should just give it a go!
>

-- 
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] Re: Output nodal scalar

[Jean-Paul Pelteret]

I can't think of any off of the top of my head, but I think that 
MatrixCreator::create_mass_matrix() 

 plus 
VectorTools::create_right_hand_side() 

 
collectively assemble what you're wanting. Its really not difficult to do 
by hand - you should just give it a go!

On Thursday, August 24, 2017 at 5:54:08 PM UTC+2, Jie Cheng wrote:
>
> Jean-Paul
>
> Any examples programming-wise? Like a deal.II manual/tutorial...
>
> Jie
>
> On Thursday, August 24, 2017 at 11:27:40 AM UTC-4, Jean-Paul Pelteret 
> wrote:
>>
>> Hi Jie,
>>
>> Sure, we used it in this paper
>>
>>> @Article{vogel2014a-preprint,
>>>   author= {Vogel, F. and Pelteret, J-P. V. and Kaessmair, S. and 
>>> Steinmann, P.},
>>>   title = {Magnetic force and torque on particles subject to a 
>>> magnetic field},
>>>   journal   = {European Journal of Mechanics A/Solids},
>>>   year  = {2014},
>>>   volume= {48},
>>>   pages = {23--31},
>>>   month = {November--December}
>>> }
>>
>>
>> but, to be honest, almost any finite element textbook should have a blurb 
>> on it. E.g. page 227 of
>>
>>> @Book{Hughes2000a,
>>>   Title= {The Finite Element Method: Linear Static 
>>> and Dynamic Finite Element Analysis},
>>>   Author   = {Hughes, T. J.},
>>>   Publisher= {Dover Publications Inc.},
>>>   Year = {2000},
>>>   Address  = {New York, USA},
>>>   Note = {ISBN: 978-0486411811},
>>> }
>>
>>
>> Regards,
>> Jean-Paul
>>
>> On Thursday, August 24, 2017 at 4:57:23 PM UTC+2, Jie Cheng wrote:
>>>
>>> Hi Jean-Paul
>>>
>>> Thanks for your help! The specific add_data_vector() function you shared 
>>> does solve my problem! For your second suggestion on L2-smoothing, I'd like 
>>> to give it a try. Can you please point me to some detailed references? 
>>> Examples or documentations would be great!
>>>
>>> Jie
>>>
>>> On Thursday, August 24, 2017 at 1:53:36 AM UTC-4, Jean-Paul Pelteret 
>>> wrote:

 Dear Jie,

 I'm glad to hear that you managed to find a solution to your problem 
 and for posting what it was. Two quick points:
 1. There's actually another add_data_vector() 
 
  
 member function of DataOut that takes in another DoFHandler as an 
 argument, 
 so you could compute the stress fields using another DoFHandler, with 
 another DataComponentInterpretation etc. This will help remedy your last 
 concern, because you will have only as many components as you need.
 2. You might want to consider solving for the smoothed stress fields 
 via global L2-smoothing rather than manual averaging. To the best of my 
 understanding, it should produce a more accurate representation of the 
 stress field than your approach. This should also be a relatively 
 inexpensive operation because solving the linear system only involves 
 inverting a mass matrix. 

 Regards,
 Jean-Paul

 On Thursday, August 24, 2017 at 5:13:29 AM UTC+2, Jie Cheng wrote:
>
> Update:
>
> I switched to my old trick of nodal averaging method: take the average 
> of the values at quadrature points, then add this average to the vertex 
> dofs. And if a vertex is shared by n cells, divide the values at the 
> related dofs by n.
> I am happy with the results because they look quite smooth.
>
> The only concern is that: for a stress component, say Sxx, appears in 
> my resulting vtu files as Sxx_0, Sxx_1 (in 2D) because the variable Sxx 
> is 
> a vector of size n_dofs as required by the add_data_vector function. Is 
> there a way to get rid of the unnecessary duplicates? Essentially I want 
> Sxx to be a vector of size n_vertices.
>
> 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.

[deal.II] Re: Output nodal scalar

[Jie Cheng]

Jean-Paul

Any examples programming-wise? Like a deal.II manual/tutorial...

Jie

On Thursday, August 24, 2017 at 11:27:40 AM UTC-4, Jean-Paul Pelteret wrote:
>
> Hi Jie,
>
> Sure, we used it in this paper
>
>> @Article{vogel2014a-preprint,
>>   author= {Vogel, F. and Pelteret, J-P. V. and Kaessmair, S. and 
>> Steinmann, P.},
>>   title = {Magnetic force and torque on particles subject to a 
>> magnetic field},
>>   journal   = {European Journal of Mechanics A/Solids},
>>   year  = {2014},
>>   volume= {48},
>>   pages = {23--31},
>>   month = {November--December}
>> }
>
>
> but, to be honest, almost any finite element textbook should have a blurb 
> on it. E.g. page 227 of
>
>> @Book{Hughes2000a,
>>   Title= {The Finite Element Method: Linear Static 
>> and Dynamic Finite Element Analysis},
>>   Author   = {Hughes, T. J.},
>>   Publisher= {Dover Publications Inc.},
>>   Year = {2000},
>>   Address  = {New York, USA},
>>   Note = {ISBN: 978-0486411811},
>> }
>
>
> Regards,
> Jean-Paul
>
> On Thursday, August 24, 2017 at 4:57:23 PM UTC+2, Jie Cheng wrote:
>>
>> Hi Jean-Paul
>>
>> Thanks for your help! The specific add_data_vector() function you shared 
>> does solve my problem! For your second suggestion on L2-smoothing, I'd like 
>> to give it a try. Can you please point me to some detailed references? 
>> Examples or documentations would be great!
>>
>> Jie
>>
>> On Thursday, August 24, 2017 at 1:53:36 AM UTC-4, Jean-Paul Pelteret 
>> wrote:
>>>
>>> Dear Jie,
>>>
>>> I'm glad to hear that you managed to find a solution to your problem and 
>>> for posting what it was. Two quick points:
>>> 1. There's actually another add_data_vector() 
>>> 
>>>  
>>> member function of DataOut that takes in another DoFHandler as an argument, 
>>> so you could compute the stress fields using another DoFHandler, with 
>>> another DataComponentInterpretation etc. This will help remedy your last 
>>> concern, because you will have only as many components as you need.
>>> 2. You might want to consider solving for the smoothed stress fields via 
>>> global L2-smoothing rather than manual averaging. To the best of my 
>>> understanding, it should produce a more accurate representation of the 
>>> stress field than your approach. This should also be a relatively 
>>> inexpensive operation because solving the linear system only involves 
>>> inverting a mass matrix. 
>>>
>>> Regards,
>>> Jean-Paul
>>>
>>> On Thursday, August 24, 2017 at 5:13:29 AM UTC+2, Jie Cheng wrote:

 Update:

 I switched to my old trick of nodal averaging method: take the average 
 of the values at quadrature points, then add this average to the vertex 
 dofs. And if a vertex is shared by n cells, divide the values at the 
 related dofs by n.
 I am happy with the results because they look quite smooth.

 The only concern is that: for a stress component, say Sxx, appears in 
 my resulting vtu files as Sxx_0, Sxx_1 (in 2D) because the variable Sxx is 
 a vector of size n_dofs as required by the add_data_vector function. Is 
 there a way to get rid of the unnecessary duplicates? Essentially I want 
 Sxx to be a vector of size n_vertices.

 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.

[deal.II] Re: Output nodal scalar

[Jean-Paul Pelteret]

Hi Jie,

Sure, we used it in this paper

> @Article{vogel2014a-preprint,
>   author= {Vogel, F. and Pelteret, J-P. V. and Kaessmair, S. and 
> Steinmann, P.},
>   title = {Magnetic force and torque on particles subject to a 
> magnetic field},
>   journal   = {European Journal of Mechanics A/Solids},
>   year  = {2014},
>   volume= {48},
>   pages = {23--31},
>   month = {November--December}
> }


but, to be honest, almost any finite element textbook should have a blurb 
on it. E.g. page 227 of

> @Book{Hughes2000a,
>   Title= {The Finite Element Method: Linear Static and 
> Dynamic Finite Element Analysis},
>   Author   = {Hughes, T. J.},
>   Publisher= {Dover Publications Inc.},
>   Year = {2000},
>   Address  = {New York, USA},
>   Note = {ISBN: 978-0486411811},
> }


Regards,
Jean-Paul

On Thursday, August 24, 2017 at 4:57:23 PM UTC+2, Jie Cheng wrote:
>
> Hi Jean-Paul
>
> Thanks for your help! The specific add_data_vector() function you shared 
> does solve my problem! For your second suggestion on L2-smoothing, I'd like 
> to give it a try. Can you please point me to some detailed references? 
> Examples or documentations would be great!
>
> Jie
>
> On Thursday, August 24, 2017 at 1:53:36 AM UTC-4, Jean-Paul Pelteret wrote:
>>
>> Dear Jie,
>>
>> I'm glad to hear that you managed to find a solution to your problem and 
>> for posting what it was. Two quick points:
>> 1. There's actually another add_data_vector() 
>> 
>>  
>> member function of DataOut that takes in another DoFHandler as an argument, 
>> so you could compute the stress fields using another DoFHandler, with 
>> another DataComponentInterpretation etc. This will help remedy your last 
>> concern, because you will have only as many components as you need.
>> 2. You might want to consider solving for the smoothed stress fields via 
>> global L2-smoothing rather than manual averaging. To the best of my 
>> understanding, it should produce a more accurate representation of the 
>> stress field than your approach. This should also be a relatively 
>> inexpensive operation because solving the linear system only involves 
>> inverting a mass matrix. 
>>
>> Regards,
>> Jean-Paul
>>
>> On Thursday, August 24, 2017 at 5:13:29 AM UTC+2, Jie Cheng wrote:
>>>
>>> Update:
>>>
>>> I switched to my old trick of nodal averaging method: take the average 
>>> of the values at quadrature points, then add this average to the vertex 
>>> dofs. And if a vertex is shared by n cells, divide the values at the 
>>> related dofs by n.
>>> I am happy with the results because they look quite smooth.
>>>
>>> The only concern is that: for a stress component, say Sxx, appears in my 
>>> resulting vtu files as Sxx_0, Sxx_1 (in 2D) because the variable Sxx is a 
>>> vector of size n_dofs as required by the add_data_vector function. Is there 
>>> a way to get rid of the unnecessary duplicates? Essentially I want Sxx to 
>>> be a vector of size n_vertices.
>>>
>>> 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.

Re: [deal.II] Using Sacado with example 15

['Maxi Miller' via deal.II User Group]

Concerning the constraints: I was refering to this line:

In the first case, there is nothing we need to do: we are using a 
> continuous finite element, and face terms do not appear in the bilinear 
> form in this case. The second case usually does not lead to face terms 
> either if we enforce hanging node constraints strongly (as in all previous 
> tutorial programs so far whenever we used continuous finite elements – this 
> enforcement is done by the ConstraintMatrix 
>  
> class together with DoFTools::make_hanging_node_constraints 
> ).
>  
> In the current program, however, we opt to enforce continuity weakly at 
> faces between cells of different refinement level, for two reasons: (i) 
> because we can, and more importantly (ii) because we would have to thread 
> the automatic differentiation we use to compute the elements of the Newton 
> matrix from the residual through the operations of the ConstraintMatrix 
>  
> class. This would be possible, but is not trivial, and so we choose this 
> alternative approach.
>

I will take a look at the code from Praveen, and try it, but it looks as if 
it needs some work (some includes are missing or shifted). But thank you 
very much!


Am Donnerstag, 24. August 2017 16:56:43 UTC+2 schrieb Wolfgang Bangerth:
>
>
> > I would like to get a feeling in working with Sacado, and would like to 
> try it 
> > on example 15. According to my understanding I now have to treat the 
> boundary 
> > conditions on my own, and not by using the ConstraintMatrix. Is that 
> still 
> > true, or was there an update since 2008? 
>
> I suspect that you are referencing a particular comment in step-33, but 
> it's 
> been so long that I can't recall what that program does. Can you point out 
> what you have in mind? 
>
> In general, as long as you have Dirichlet boundary conditions, they can be 
> handled by ConstraintMatrix at the time when the local matrix is 
> distributed 
> into the global matrix, and that happens after all of the Sacado magic 
> happens 
> -- you get the local matrix out of Sacado and then copy it into the global 
> matrix. 
>
>
> > Furthermore, now the function F() is depending on the gradient of u, and 
> not 
> > as in example 33 depending on u, else it should look like exactly in 
> example 
> > 33 (in both examples we have \nabla F(u)). Is that correct? Nevertheless 
> I 
> > assume that I need the numerical flux function due to having to check 
> the 
> > dangling nodes. 
>
> You can also handle hanging nodes as is always done, via ConstraintMatrix. 
> step-33 does it differently not because that is necessary but because the 
> author decided that he could. 
>
> I think that using Sacado (or in general, automatic differentiation) 
> should be 
> relatively straightforward in step-15, in particular because the residual 
> is 
> already computed there. I'd just give it a try and see what is necessary. 
> You 
> may want to use the current developer version of deal.II -- there have 
> been 
> numerous changes in recent weeks to make AD easier to use in the FEValues 
> class, in particular through functions such as 
> FEValues::get_function_{values,gradients}. 
>
> Using AD in step-15 is an interesting project. If you make it work, would 
> you 
> mind sending the assembly function to the mailing list? I think it would 
> make 
> for a great section in the "Possibilities for extensions" section of 
> step-15! 
>
> 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.

Re: [deal.II] Using Sacado with example 15

[Praveen C]

I did this a while back, see here

https://bitbucket.org/cpraveen/deal_ii/src/865f1c963f1089a870054bebf7180c9712e93da8/step-15-sacado/?at=master

Best
praveen

On Thu, Aug 24, 2017 at 8:26 PM, Wolfgang Bangerth 
wrote:

>
> I would like to get a feeling in working with Sacado, and would like to
>> try it on example 15. According to my understanding I now have to treat the
>> boundary conditions on my own, and not by using the ConstraintMatrix. Is
>> that still true, or was there an update since 2008?
>>
>
> I suspect that you are referencing a particular comment in step-33, but
> it's been so long that I can't recall what that program does. Can you point
> out what you have in mind?
>
> In general, as long as you have Dirichlet boundary conditions, they can be
> handled by ConstraintMatrix at the time when the local matrix is
> distributed into the global matrix, and that happens after all of the
> Sacado magic happens -- you get the local matrix out of Sacado and then
> copy it into the global matrix.
>
>
> Furthermore, now the function F() is depending on the gradient of u, and
>> not as in example 33 depending on u, else it should look like exactly in
>> example 33 (in both examples we have \nabla F(u)). Is that correct?
>> Nevertheless I assume that I need the numerical flux function due to having
>> to check the dangling nodes.
>>
>
> You can also handle hanging nodes as is always done, via ConstraintMatrix.
> step-33 does it differently not because that is necessary but because the
> author decided that he could.
>
> I think that using Sacado (or in general, automatic differentiation)
> should be relatively straightforward in step-15, in particular because the
> residual is already computed there. I'd just give it a try and see what is
> necessary. You may want to use the current developer version of deal.II --
> there have been numerous changes in recent weeks to make AD easier to use
> in the FEValues class, in particular through functions such as
> FEValues::get_function_{values,gradients}.
>
> Using AD in step-15 is an interesting project. If you make it work, would
> you mind sending the assembly function to the mailing list? I think it
> would make for a great section in the "Possibilities for extensions"
> section of step-15!
>
> 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/fo
> rum/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] Re: Multiply SparseMatrix and a Vector

[Nitish Anand]

In fact, that was the issue.. Works well now. :) Thanks ! 

On Thursday, August 24, 2017 at 4:21:59 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Dear Nitish,
>
> Well, in the documentation to vmult 
> 
>  it 
> states that when
>
>> the current object represents a parallel distributed matrix (of type 
>> PETScWrappers::MPI::SparseMatrix 
>> ),
>>  
>> then both vectors have to be distributed vectors as well
>
> . So I suspect that what you need to do is to create a pair of distributed 
> vectors and then simply copy the data from the deal.II vector to the PETSc 
> one using operator= 
> 
> .
>
> Does this help?
>
> Regards,
> Jean-Paul
>
> On Thursday, August 24, 2017 at 4:17:36 PM UTC+2, Nitish Anand wrote:
>>
>> Errata: PETSc 
>>
>> On Thursday, August 24, 2017 at 4:14:56 PM UTC+2, Nitish Anand wrote:
>>>
>>> Hello,
>>>
>>> I wish to multiply a PETSeWrapper::MPI::SparseMatrix with a 
>>> Vector. I would be glad if someone can point to the right material 
>>> to do this efficiently.
>>>
>>> Thanks in advance.
>>>
>>> --Nitish
>>>
>>

-- 
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] Re: Output nodal scalar

[Jie Cheng]

Hi Jean-Paul

Thanks for your help! The specific add_data_vector() function you shared 
does solve my problem! For your second suggestion on L2-smoothing, I'd like 
to give it a try. Can you please point me to some detailed references? 
Examples or documentations would be great!

Jie

On Thursday, August 24, 2017 at 1:53:36 AM UTC-4, Jean-Paul Pelteret wrote:
>
> Dear Jie,
>
> I'm glad to hear that you managed to find a solution to your problem and 
> for posting what it was. Two quick points:
> 1. There's actually another add_data_vector() 
> 
>  
> member function of DataOut that takes in another DoFHandler as an argument, 
> so you could compute the stress fields using another DoFHandler, with 
> another DataComponentInterpretation etc. This will help remedy your last 
> concern, because you will have only as many components as you need.
> 2. You might want to consider solving for the smoothed stress fields via 
> global L2-smoothing rather than manual averaging. To the best of my 
> understanding, it should produce a more accurate representation of the 
> stress field than your approach. This should also be a relatively 
> inexpensive operation because solving the linear system only involves 
> inverting a mass matrix. 
>
> Regards,
> Jean-Paul
>
> On Thursday, August 24, 2017 at 5:13:29 AM UTC+2, Jie Cheng wrote:
>>
>> Update:
>>
>> I switched to my old trick of nodal averaging method: take the average of 
>> the values at quadrature points, then add this average to the vertex dofs. 
>> And if a vertex is shared by n cells, divide the values at the related dofs 
>> by n.
>> I am happy with the results because they look quite smooth.
>>
>> The only concern is that: for a stress component, say Sxx, appears in my 
>> resulting vtu files as Sxx_0, Sxx_1 (in 2D) because the variable Sxx is a 
>> vector of size n_dofs as required by the add_data_vector function. Is there 
>> a way to get rid of the unnecessary duplicates? Essentially I want Sxx to 
>> be a vector of size n_vertices.
>>
>> 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.

Re: [deal.II] Using Sacado with example 15

[Wolfgang Bangerth]

I would like to get a feeling in working with Sacado, and would like to try it 
on example 15. According to my understanding I now have to treat the boundary 
conditions on my own, and not by using the ConstraintMatrix. Is that still 
true, or was there an update since 2008?


I suspect that you are referencing a particular comment in step-33, but it's 
been so long that I can't recall what that program does. Can you point out 
what you have in mind?


In general, as long as you have Dirichlet boundary conditions, they can be 
handled by ConstraintMatrix at the time when the local matrix is distributed 
into the global matrix, and that happens after all of the Sacado magic happens 
-- you get the local matrix out of Sacado and then copy it into the global matrix.



Furthermore, now the function F() is depending on the gradient of u, and not 
as in example 33 depending on u, else it should look like exactly in example 
33 (in both examples we have \nabla F(u)). Is that correct? Nevertheless I 
assume that I need the numerical flux function due to having to check the 
dangling nodes.


You can also handle hanging nodes as is always done, via ConstraintMatrix. 
step-33 does it differently not because that is necessary but because the 
author decided that he could.


I think that using Sacado (or in general, automatic differentiation) should be 
relatively straightforward in step-15, in particular because the residual is 
already computed there. I'd just give it a try and see what is necessary. You 
may want to use the current developer version of deal.II -- there have been 
numerous changes in recent weeks to make AD easier to use in the FEValues 
class, in particular through functions such as 
FEValues::get_function_{values,gradients}.


Using AD in step-15 is an interesting project. If you make it work, would you 
mind sending the assembly function to the mailing list? I think it would make 
for a great section in the "Possibilities for extensions" section of step-15!


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] Using deal.II logo in publication

[Wolfgang Bangerth]

On 08/24/2017 08:02 AM, Matthias Maier wrote:

Martin -- good question. I don't think anyone has ever thought about
this. I would say go ahead and use it. Certainly, as the person who
created that picture, I have no objections.

What about we put a small licensing blurb on the homepage? Something
like "CC BY 4.0" [1].


That sounds reasonable. But where would be a good place to put this?

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.

[deal.II] Re: Multiply SparseMatrix and a Vector

[Jean-Paul Pelteret]

Dear Nitish,

Well, in the documentation to vmult 

 it 
states that when

> the current object represents a parallel distributed matrix (of type 
> PETScWrappers::MPI::SparseMatrix 
> ),
>  
> then both vectors have to be distributed vectors as well

. So I suspect that what you need to do is to create a pair of distributed 
vectors and then simply copy the data from the deal.II vector to the PETSc 
one using operator= 

.

Does this help?

Regards,
Jean-Paul

On Thursday, August 24, 2017 at 4:17:36 PM UTC+2, Nitish Anand wrote:
>
> Errata: PETSc 
>
> On Thursday, August 24, 2017 at 4:14:56 PM UTC+2, Nitish Anand wrote:
>>
>> Hello,
>>
>> I wish to multiply a PETSeWrapper::MPI::SparseMatrix with a 
>> Vector. I would be glad if someone can point to the right material 
>> to do this efficiently.
>>
>> Thanks in advance.
>>
>> --Nitish
>>
>

-- 
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] Re: Multiply SparseMatrix and a Vector

[Nitish Anand]

Errata: PETSc 

On Thursday, August 24, 2017 at 4:14:56 PM UTC+2, Nitish Anand wrote:
>
> Hello,
>
> I wish to multiply a PETSeWrapper::MPI::SparseMatrix with a 
> Vector. I would be glad if someone can point to the right material 
> to do this efficiently.
>
> Thanks in advance.
>
> --Nitish
>

-- 
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] Multiply SparseMatrix and a Vector

[Nitish Anand]

Hello,

I wish to multiply a PETSeWrapper::MPI::SparseMatrix with a Vector. 
I would be glad if someone can point to the right material to do this 
efficiently.

Thanks in advance.

--Nitish

-- 
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] Using deal.II logo in publication

[Matthias Maier]

On Thu, Aug 24, 2017, at 08:22 CDT, Wolfgang Bangerth  
wrote:

> Martin -- good question. I don't think anyone has ever thought about
> this. I would say go ahead and use it. Certainly, as the person who
> created that picture, I have no objections.

What about we put a small licensing blurb on the homepage? Something
like "CC BY 4.0" [1].

Best,
Matthias



[1] https://creativecommons.org/licenses/by/4.0/

-- 
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] Using deal.II logo in publication

[Wolfgang Bangerth]

On 08/23/2017 06:39 PM, Martin Diehl wrote:


I've written a short overview article on continuum scale modeling in which I 
mention deal.II (including the preferred reference and a link to the homepage).
For an attractive paper, I want to include the deal.II-Logo. Are there any 
specific regulations regarding the use of the logo? As far as I figured out, 
it's also open source but since licensing of images and code is rather 
different I want to make sure if it is ok. I would of course share the article 
before publication in case you're interested in the content.


Martin -- good question. I don't think anyone has ever thought about this. I 
would say go ahead and use it. Certainly, as the person who created that 
picture, I have no objections.


We do want to get a link to the article, though, so we can list it on the list 
of publications at

  http://dealii.org/publications.html
We'd appreciate if you could send us a reference once it's published! :-)

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.

[deal.II] Using Sacado with example 15

['Maxi Miller' via deal.II User Group]

I would like to get a feeling in working with Sacado, and would like to try 
it on example 15. According to my understanding I now have to treat the 
boundary conditions on my own, and not by using the ConstraintMatrix. Is 
that still true, or was there an update since 2008?

Furthermore, now the function F() is depending on the gradient of u, and 
not as in example 33 depending on u, else it should look like exactly in 
example 33 (in both examples we have \nabla F(u)). Is that correct? 
Nevertheless I assume that I need the numerical flux function due to having 
to check the dangling nodes.

Are those assumptions correct? I would like to have the theory first before 
starting to modify/write programs...
Thanks!

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