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

[Matthias Maier]

On Mon, Aug 28, 2017, at 16:12 CDT, Denis Davydov  wrote:

> FYI, this logo is done with a help of qualified (master degree) graphic 
> designer.

I like it very much. +1

Further, the somewhat different color scheme is also very much
appreciated!

We shouldn't have the "jet color bar" in our logo - it is a terrible
choice :-]



I suggest, we simply put a small number of alternative designs on a
webpage and have a vote (the whole community included). 

Best,
Matthias

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

[Denis Davydov]

FYI, this logo is done with a help of qualified (master degree) graphic 
designer.

On Monday, August 28, 2017 at 11:09:33 PM UTC+2, Timo Heister wrote:
>
> Personally, I prefer the colors and font I used. I like the green dot 
> though! 
>
> On Mon, Aug 28, 2017 at 5:05 PM, Denis Davydov  > wrote: 
> > Ok, here's my final suggestion for a logo. 
> > The writing is based on Courier IBM, changed to curves and further 
> tweaked. 
> > Three colours are print friendly. 
> > 
> > Regards, 
> > Denis. 
> > 
> > On Monday, August 28, 2017 at 5:59:16 PM UTC+2, Wolfgang Bangerth wrote: 
> >> 
> >> On 08/28/2017 09:35 AM, Matthias Maier wrote: 
> >> > As already mentioned off-list. 
> >> > 
> >> > We should switch to a font with a clear and open license anyway. 
> >> > 
> >> > Maybe the twentieth anniversary is a perfect opportunity to slightly 
> >> > change the logo (and colors)?:-) 
> >> 
> >> I think that proposing to use a different font is fair game while we 
> >> look at the logo. I don't have a particular preference though I think 
> an 
> >> upright and clean font looks best. 
> >> 
> >> Best 
> >>   W. 
> >> 
> >> -- 
> >> 
>  
> >> Wolfgang Bangerth  email: bang...@colostate.edu 
> >> www: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.math.colostate.edu_-7Ebangerth_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=75bPffEy-zAuROXcnVn9AgfRbahWA6ufCZwVAYRYGnE=
>  
> > 
> > -- 
> > The deal.II project is located at 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=nHyL_JGldywEA58_hIbBLxNM6fCBs3RSmiPyuY50-O4=
>  
> > For mailing list/forum options, see 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_forum_dealii-3Fhl-3Den=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=4dx7varHluxvCKa9uz1-YUDfln0RJtImWN0d4LZvTX0=
>  
> > --- 
> > 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://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=BHhfVtF3RL6Xl_ss1wFpnd-bqYaX6IXDQF_RL32phBM=
>  
> . 
>
>
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

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

[Timo Heister]

Personally, I prefer the colors and font I used. I like the green dot though!

On Mon, Aug 28, 2017 at 5:05 PM, Denis Davydov  wrote:
> Ok, here's my final suggestion for a logo.
> The writing is based on Courier IBM, changed to curves and further tweaked.
> Three colours are print friendly.
>
> Regards,
> Denis.
>
> On Monday, August 28, 2017 at 5:59:16 PM UTC+2, Wolfgang Bangerth wrote:
>>
>> On 08/28/2017 09:35 AM, Matthias Maier wrote:
>> > As already mentioned off-list.
>> >
>> > We should switch to a font with a clear and open license anyway.
>> >
>> > Maybe the twentieth anniversary is a perfect opportunity to slightly
>> > change the logo (and colors)?:-)
>>
>> I think that proposing to use a different font is fair game while we
>> look at the logo. I don't have a particular preference though I think an
>> upright and clean font looks best.
>>
>> Best
>>   W.
>>
>> --
>> 
>> Wolfgang Bangerth  email: bang...@colostate.edu
>> www: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.math.colostate.edu_-7Ebangerth_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=75bPffEy-zAuROXcnVn9AgfRbahWA6ufCZwVAYRYGnE=
>>  
>
> --
> The deal.II project is located at 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=nHyL_JGldywEA58_hIbBLxNM6fCBs3RSmiPyuY50-O4=
>  
> For mailing list/forum options, see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_forum_dealii-3Fhl-3Den=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=4dx7varHluxvCKa9uz1-YUDfln0RJtImWN0d4LZvTX0=
>  
> ---
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=BHhfVtF3RL6Xl_ss1wFpnd-bqYaX6IXDQF_RL32phBM=
>  .



-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
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] modifying of only one component of solution

[Wolfgang Bangerth]

On 08/27/2017 11:53 AM, Marek Čapek wrote:



I am getting the solution in

   PetscWrappers::MPI::Vector solution_phase_n;

I am interested in modifying the vector of the solution - I
want to cut the undershoots and overshoots in phase-field component
of the solution. Namely I have values of phase field like -1.005 or 1.005,
however they should be only in <-1,1>.
Is it possible to modify only the relevant parts of the
PetscWrappers::MPI::Vector ?

I want to get  afterwards the solution values and gradients using

fe_v_phase.get_function_values
fe_v_phase.get_function_gradients

to get the "repaired" values and gradients of phase field.

Or should I split the system, ie. firstly solve for the phase
field, then modify the phase field solution and afterwards
solve for chemical potential?


The easiest solution is probably to use a 
PETScWrappers::MPI::BlockVector with two blocks that corresponds to the 
two variables. You would then just apply the operation on one of the 
blocks. This may require you to also substructure your matrix into 
blocks, but all of your solvers should continue to work. In particular, 
just because your matrix is substructured does not imply that you have 
to solve one equation at the time (though you can).


The alternative is to figure out which elements of your vector 
correspond to the phase-field. Namespace DoFTools has functions that 
give you a mask or IndexSet that indicates which variables belong to one 
particular vector component. You would then just operate on those vector 
elements that are listed in the mask/IndexSet.


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] Re: Anisotropic fe space

[Wolfgang Bangerth]

On 08/28/2017 09:42 AM, Praveen C wrote:
Yes, I could use FE_RaviartThomasNodal(k-1) to get the test 
functions, though I would have liked to choose other nodes.


Then I don't think I understand what the original question was. Do you 
need an element, or just the polynomials? For the latter, you can still 
see how FE_RTNodal constructs the polynomials it then uses as its shape 
functions.


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/28/2017 09:35 AM, Matthias Maier wrote:

As already mentioned off-list.

We should switch to a font with a clear and open license anyway.

Maybe the twentieth anniversary is a perfect opportunity to slightly
change the logo (and colors)?:-)


I think that proposing to use a different font is fair game while we 
look at the logo. I don't have a particular preference though I think an 
upright and clean font looks best.


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] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Dear Lucas,

Great! We're looking forward to adding you to the list of contributors 
 to the project :-)

J-P

On Monday, August 28, 2017 at 5:42:30 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> I can definitely do it. 
>
> Lucas
>
> On 28 August 2017 at 17:40, Jean-Paul Pelteret <> wrote:
>
>> Dear Lucas,
>>
>> You're welcome. Thanks for the discussion and your feedback! I've made a 
>> note to myself  to improve 
>> the documentation in this area, but if you want a small side-project then 
>> feel free to propose the amendments yourself with a pull request to the 
>> GitHub repository :-) I'd be happy to help you out if you want / need it.
>>
>> J-P
>>
>> On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>>>
>>> Dear Jean-Paul,
>>>
>>> Thanks again. Now I do understand and it all makes sense. 
>>>
>>> Also, while yes, I agree that the lack of the else could lead to errors 
>>> that quite hard to track down. However, I think adding your comment to that 
>>> part of the tutorial could save someone having the same issues I faced.
>>>
>>> Thanks for your time,
>>> Lucas
>>>
>>> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>>>
 Hi Lucas,

 I see, now I understand to what you were referring. 

 Yes, the specific example that you've shown here is an intentional 
 redundancy. Previous experiences has shown that we all have a tendency to 
 copy-paste the tutorials and work from them (that is their intended use 
 after all :-). I put this in place to ensure that one doesn't accidentally 
 forget the "else" case when refactoring this code. It would be very easy 
 to 
 do, and could be a tricky error to track down. Furthermore, it also 
 reinforces what was discussed in the introductory paragraph above it.

 So I agree fully that this is not required. One could in fact reduce 
 this entire implementation of the constraints to only a few lines. But in 
 the interest of clarity it will remain in its current form for now :-)

 Regards,
 Jean-Paul

 On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks for your answer! Still, I am not sure if I understand the code. 
> The main issue seems to be that both blocks in every if else path are the 
> exactly the same. For instance, 
>
> if (apply_dirichlet_bc == true)
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>> else
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>>
>
>  What is the use of having if-else in this situation? 
>
> Also, in your answer you mentioned that in the second call (iteration 
> == 1), only homogeneous constrains will be built. I also cannot see this 
> from the code. Perhaps this part is interacting with some other part of 
> the 
> code in a way I cannot see?
>
> Thanks for the help,
> Lucas Campos
>
> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> So it sounds as if you've already worked out what's happening here. 
>> We consider 3 cases, namely what to do for newton iteration equal to 0, 
>> equal to 1, and greater than 1.
>>
>> For iteration == 0 and iteration == 1, the early return on line 2468 
>> 
>>  
>> is not satisfied and we have to build some dirichlet constraints. Which 
>> constraints are build is governed by the iteration number: if it is 
>> equal 
>> to zero, then apply_dirichlet_BC 
>> 
>>  
>> is set true and we build non-homogeneous constraints (the "if" case). On 
>> the next visit to this function (iteration == 1) this flag is set to 
>> false 

Re: [deal.II] Re: if else leading to the same path in step 44

[Lucas Campos]

Dear Jean-Paul,

I can definitely do it.

Lucas

On 28 August 2017 at 17:40, Jean-Paul Pelteret  wrote:

> Dear Lucas,
>
> You're welcome. Thanks for the discussion and your feedback! I've made a
> note to myself  to improve
> the documentation in this area, but if you want a small side-project then
> feel free to propose the amendments yourself with a pull request to the
> GitHub repository :-) I'd be happy to help you out if you want / need it.
>
> J-P
>
> On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>>
>> Dear Jean-Paul,
>>
>> Thanks again. Now I do understand and it all makes sense.
>>
>> Also, while yes, I agree that the lack of the else could lead to errors
>> that quite hard to track down. However, I think adding your comment to that
>> part of the tutorial could save someone having the same issues I faced.
>>
>> Thanks for your time,
>> Lucas
>>
>> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>>
>>> Hi Lucas,
>>>
>>> I see, now I understand to what you were referring.
>>>
>>> Yes, the specific example that you've shown here is an intentional
>>> redundancy. Previous experiences has shown that we all have a tendency to
>>> copy-paste the tutorials and work from them (that is their intended use
>>> after all :-). I put this in place to ensure that one doesn't accidentally
>>> forget the "else" case when refactoring this code. It would be very easy to
>>> do, and could be a tricky error to track down. Furthermore, it also
>>> reinforces what was discussed in the introductory paragraph above it.
>>>
>>> So I agree fully that this is not required. One could in fact reduce
>>> this entire implementation of the constraints to only a few lines. But in
>>> the interest of clarity it will remain in its current form for now :-)
>>>
>>> Regards,
>>> Jean-Paul
>>>
>>> On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:

 Dear Jean-Paul,

 Thanks for your answer! Still, I am not sure if I understand the code.
 The main issue seems to be that both blocks in every if else path are the
 exactly the same. For instance,

 if (apply_dirichlet_bc == true)
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
> else
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
>

  What is the use of having if-else in this situation?

 Also, in your answer you mentioned that in the second call (iteration
 == 1), only homogeneous constrains will be built. I also cannot see this
 from the code. Perhaps this part is interacting with some other part of the
 code in a way I cannot see?

 Thanks for the help,
 Lucas Campos

 On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:

> Hi Lucas,
>
> So it sounds as if you've already worked out what's happening here. We
> consider 3 cases, namely what to do for newton iteration equal to 0, equal
> to 1, and greater than 1.
>
> For iteration == 0 and iteration == 1, the early return on line 2468
> 
> is not satisfied and we have to build some dirichlet constraints. Which
> constraints are build is governed by the iteration number: if it is equal
> to zero, then apply_dirichlet_BC
> 
> is set true and we build non-homogeneous constraints (the "if" case). On
> the next visit to this function (iteration == 1) this flag is set to false
> and we build only homogeneous constraints (the "else" case). At subsequent
> iterations we use the early return that I previously mentioned to make no
> further changes to the existing constraint matrix. This is because it is
> already filled with the homogeneous constraints, which is what we want for
> all newton iterations > 0.
>
> Does this make sense?
>
> 

Re: [deal.II] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Dear Lucas,

You're welcome. Thanks for the discussion and your feedback! I've made a 
note to myself  to improve 
the documentation in this area, but if you want a small side-project then 
feel free to propose the amendments yourself with a pull request to the 
GitHub repository :-) I'd be happy to help you out if you want / need it.

J-P

On Monday, August 28, 2017 at 5:35:10 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks again. Now I do understand and it all makes sense. 
>
> Also, while yes, I agree that the lack of the else could lead to errors 
> that quite hard to track down. However, I think adding your comment to that 
> part of the tutorial could save someone having the same issues I faced.
>
> Thanks for your time,
> Lucas
>
> On 28 August 2017 at 17:26, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> I see, now I understand to what you were referring. 
>>
>> Yes, the specific example that you've shown here is an intentional 
>> redundancy. Previous experiences has shown that we all have a tendency to 
>> copy-paste the tutorials and work from them (that is their intended use 
>> after all :-). I put this in place to ensure that one doesn't accidentally 
>> forget the "else" case when refactoring this code. It would be very easy to 
>> do, and could be a tricky error to track down. Furthermore, it also 
>> reinforces what was discussed in the introductory paragraph above it.
>>
>> So I agree fully that this is not required. One could in fact reduce this 
>> entire implementation of the constraints to only a few lines. But in the 
>> interest of clarity it will remain in its current form for now :-)
>>
>> Regards,
>> Jean-Paul
>>
>> On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>>>
>>> Dear Jean-Paul,
>>>
>>> Thanks for your answer! Still, I am not sure if I understand the code. 
>>> The main issue seems to be that both blocks in every if else path are the 
>>> exactly the same. For instance, 
>>>
>>> if (apply_dirichlet_bc == true)
 VectorTools::interpolate_boundary_values 
 
 (dof_handler_ref,
 boundary_id,
 Functions::ZeroFunction 
 
 (n_components),
 constraints,
 fe.component_mask 
 
 (x_displacement));
 else
 VectorTools::interpolate_boundary_values 
 
 (dof_handler_ref,
 boundary_id,
 Functions::ZeroFunction 
 
 (n_components),
 constraints,
 fe.component_mask 
 
 (x_displacement));

>>>
>>>  What is the use of having if-else in this situation? 
>>>
>>> Also, in your answer you mentioned that in the second call (iteration == 
>>> 1), only homogeneous constrains will be built. I also cannot see this from 
>>> the code. Perhaps this part is interacting with some other part of the code 
>>> in a way I cannot see?
>>>
>>> Thanks for the help,
>>> Lucas Campos
>>>
>>> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>>>
 Hi Lucas,

 So it sounds as if you've already worked out what's happening here. We 
 consider 3 cases, namely what to do for newton iteration equal to 0, equal 
 to 1, and greater than 1.

 For iteration == 0 and iteration == 1, the early return on line 2468 
 
  
 is not satisfied and we have to build some dirichlet constraints. Which 
 constraints are build is governed by the iteration number: if it is equal 
 to zero, then apply_dirichlet_BC 
 
  
 is set true and we build non-homogeneous constraints (the "if" case). On 
 the next visit to this function (iteration == 1) this flag is set to false 
 and we build only homogeneous constraints (the "else" case). At subsequent 
 iterations we use the early return that I previously mentioned to make no 
 further changes to the existing constraint matrix. This is because it is 
 already filled with the homogeneous constraints, which is what we want for 
 all newton iterations > 0.

 Does this make sense?

 Regards,
 Jean-Paul

 On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>
> > This calculation does not happen anyway, because of the early return 
> 

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

[Denis Davydov]

I am fine with adjusting colours, but I like the IBM Courier font as it has 
relevant history behind. 
I believe it is this font which is currently used on a low resolution logo and 
to my knowledge this font is royalty free.
So i would stick with it.

> On 28 Aug 2017, at 17:35, Matthias Maier  wrote:
> 
> As already mentioned off-list.
> 
> We should switch to a font with a clear and open license anyway.
> 
> Maybe the twentieth anniversary is a perfect opportunity to slightly
> change the logo (and colors)? :-)
> 
> Best,
> Matthias
> 
> 
> On Mon, Aug 28, 2017, at 10:05 CDT, Jean-Paul Pelteret  
> wrote:
> 
>> Maybe, but its not our current logo but rather a new one? ;-)
>> 
>> On Monday, August 28, 2017 at 5:00:12 PM UTC+2, Timo Heister wrote:
>>> 
>>> My counter: 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__files.gitter.im_dealii_itGp_logo.png=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=w-OWsHSFKFvDnpVW9zIrDHHbhcbF69VVZ8_l2TDrs14=7eUaIGiXA633AbVNkMhhGfFdN0m9fwdDWm8xewuKO48=
>>> 
>>> nicer font and nicer colors in my opinion. 
>>> 
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/VkYm3p1I6qQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Using deal.II logo in publication

[Matthias Maier]

As already mentioned off-list.

We should switch to a font with a clear and open license anyway.

Maybe the twentieth anniversary is a perfect opportunity to slightly
change the logo (and colors)? :-)

Best,
Matthias


On Mon, Aug 28, 2017, at 10:05 CDT, Jean-Paul Pelteret  
wrote:

> Maybe, but its not our current logo but rather a new one? ;-)
>
> On Monday, August 28, 2017 at 5:00:12 PM UTC+2, Timo Heister wrote:
>>
>> My counter: 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__files.gitter.im_dealii_itGp_logo.png=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=w-OWsHSFKFvDnpVW9zIrDHHbhcbF69VVZ8_l2TDrs14=7eUaIGiXA633AbVNkMhhGfFdN0m9fwdDWm8xewuKO48=
>> 
>> nicer font and nicer colors in my opinion. 
>>

-- 
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] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Hi Lucus,

To add to what I just said (and to try to answer your question more fully / 
properly), this particular problem admittedly only has homogeneous 
constraints. See some of the code-gallery examples 
, e.g. this one 
,
 
for a case where non-homogeneous boundary conditions are applied. This 
better illustrates that the discussion in this part of the tutorial is 
about.

Regards,
Jean-Paul

On Monday, August 28, 2017 at 5:26:08 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Hi Lucas,
>
> I see, now I understand to what you were referring. 
>
> Yes, the specific example that you've shown here is an intentional 
> redundancy. Previous experiences has shown that we all have a tendency to 
> copy-paste the tutorials and work from them (that is their intended use 
> after all :-). I put this in place to ensure that one doesn't accidentally 
> forget the "else" case when refactoring this code. It would be very easy to 
> do, and could be a tricky error to track down. Furthermore, it also 
> reinforces what was discussed in the introductory paragraph above it.
>
> So I agree fully that this is not required. One could in fact reduce this 
> entire implementation of the constraints to only a few lines. But in the 
> interest of clarity it will remain in its current form for now :-)
>
> Regards,
> Jean-Paul
>

-- 
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] Re: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Hi Lucas,

I see, now I understand to what you were referring. 

Yes, the specific example that you've shown here is an intentional 
redundancy. Previous experiences has shown that we all have a tendency to 
copy-paste the tutorials and work from them (that is their intended use 
after all :-). I put this in place to ensure that one doesn't accidentally 
forget the "else" case when refactoring this code. It would be very easy to 
do, and could be a tricky error to track down. Furthermore, it also 
reinforces what was discussed in the introductory paragraph above it.

So I agree fully that this is not required. One could in fact reduce this 
entire implementation of the constraints to only a few lines. But in the 
interest of clarity it will remain in its current form for now :-)

Regards,
Jean-Paul

On Monday, August 28, 2017 at 5:14:52 PM UTC+2, Lucas Campos wrote:
>
> Dear Jean-Paul,
>
> Thanks for your answer! Still, I am not sure if I understand the code. The 
> main issue seems to be that both blocks in every if else path are the 
> exactly the same. For instance, 
>
> if (apply_dirichlet_bc == true)
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>> else
>> VectorTools::interpolate_boundary_values 
>> 
>> (dof_handler_ref,
>> boundary_id,
>> Functions::ZeroFunction 
>> 
>> (n_components),
>> constraints,
>> fe.component_mask 
>> 
>> (x_displacement));
>>
>
>  What is the use of having if-else in this situation? 
>
> Also, in your answer you mentioned that in the second call (iteration == 
> 1), only homogeneous constrains will be built. I also cannot see this from 
> the code. Perhaps this part is interacting with some other part of the code 
> in a way I cannot see?
>
> Thanks for the help,
> Lucas Campos
>
> On 28 August 2017 at 17:03, Jean-Paul Pelteret <> wrote:
>
>> Hi Lucas,
>>
>> So it sounds as if you've already worked out what's happening here. We 
>> consider 3 cases, namely what to do for newton iteration equal to 0, equal 
>> to 1, and greater than 1.
>>
>> For iteration == 0 and iteration == 1, the early return on line 2468 
>> 
>>  
>> is not satisfied and we have to build some dirichlet constraints. Which 
>> constraints are build is governed by the iteration number: if it is equal 
>> to zero, then apply_dirichlet_BC 
>> 
>>  
>> is set true and we build non-homogeneous constraints (the "if" case). On 
>> the next visit to this function (iteration == 1) this flag is set to false 
>> and we build only homogeneous constraints (the "else" case). At subsequent 
>> iterations we use the early return that I previously mentioned to make no 
>> further changes to the existing constraint matrix. This is because it is 
>> already filled with the homogeneous constraints, which is what we want for 
>> all newton iterations > 0.
>>
>> Does this make sense?
>>
>> Regards,
>> Jean-Paul
>>
>> On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>>>
>>> > This calculation does not happen anyway, because of the early return 
>>> in line 2466. 
>>>
>>> Just a minor correction for the previous sentence: The guard on line 
>>> 2466 will be true only on the second iterations. The else paths will still 
>>> be taken at least once.
>>>
>>> On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:

 Dear all,

 First of all, thanks for the great library! I spent the last few days 
 reading your (very!) extensive 
 documentation and I think it will be really useful for me in the near 
 future. 

 Right now I am struggling a bit on understanding some things on 
 step-44. Most pressing right 
 now is that, in Section Solid::make_constraints of the tutorials, we 
 have 

 > However, since we are dealing with an iterative Newton method, it 
 should be noted 
 > that any displacement constraints should only be specified at the 
 zeroth iteration 
 > and subsequently no additional contributions are to be made since the 
 constraints 
 > are already exactly satisfied.

 However, reading the code underneath, 

Re: [deal.II] Re: if else leading to the same path in step 44

[Lucas Campos]

Dear Jean-Paul,

Thanks for your answer! Still, I am not sure if I understand the code. The
main issue seems to be that both blocks in every if else path are the
exactly the same. For instance,

if (apply_dirichlet_bc == true)
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
> else
> VectorTools::interpolate_boundary_values
> 
> (dof_handler_ref,
> boundary_id,
> Functions::ZeroFunction
> 
> (n_components),
> constraints,
> fe.component_mask
> 
> (x_displacement));
>

 What is the use of having if-else in this situation?

Also, in your answer you mentioned that in the second call (iteration ==
1), only homogeneous constrains will be built. I also cannot see this from
the code. Perhaps this part is interacting with some other part of the code
in a way I cannot see?

Thanks for the help,
Lucas Campos

On 28 August 2017 at 17:03, Jean-Paul Pelteret  wrote:

> Hi Lucas,
>
> So it sounds as if you've already worked out what's happening here. We
> consider 3 cases, namely what to do for newton iteration equal to 0, equal
> to 1, and greater than 1.
>
> For iteration == 0 and iteration == 1, the early return on line 2468
> 
> is not satisfied and we have to build some dirichlet constraints. Which
> constraints are build is governed by the iteration number: if it is equal
> to zero, then apply_dirichlet_BC
> 
> is set true and we build non-homogeneous constraints (the "if" case). On
> the next visit to this function (iteration == 1) this flag is set to false
> and we build only homogeneous constraints (the "else" case). At subsequent
> iterations we use the early return that I previously mentioned to make no
> further changes to the existing constraint matrix. This is because it is
> already filled with the homogeneous constraints, which is what we want for
> all newton iterations > 0.
>
> Does this make sense?
>
> Regards,
> Jean-Paul
>
> On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>>
>> > This calculation does not happen anyway, because of the early return in
>> line 2466.
>>
>> Just a minor correction for the previous sentence: The guard on line 2466
>> will be true only on the second iterations. The else paths will still be
>> taken at least once.
>>
>> On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:
>>>
>>> Dear all,
>>>
>>> First of all, thanks for the great library! I spent the last few days
>>> reading your (very!) extensive
>>> documentation and I think it will be really useful for me in the near
>>> future.
>>>
>>> Right now I am struggling a bit on understanding some things on step-44.
>>> Most pressing right
>>> now is that, in Section Solid::make_constraints of the tutorials, we
>>> have
>>>
>>> > However, since we are dealing with an iterative Newton method, it
>>> should be noted
>>> > that any displacement constraints should only be specified at the
>>> zeroth iteration
>>> > and subsequently no additional contributions are to be made since the
>>> constraints
>>> > are already exactly satisfied.
>>>
>>> However, reading the code underneath, the code under the if-else blocks
>>> are the same (around
>>> line 2490 of step-44.cc). That is to say, we would run the same
>>> computation whether the condition
>>> is true or false. This calculation does not happen anyway, because of
>>> the early return in line 2466.
>>> If we disregard this early return, would this code be wrong, or is there
>>> something I am not seeing?
>>>
>>> Bests,
>>> Lucas
>>>
>> --
> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/dealii/TSUwtKqcotY/unsubscribe.
> To unsubscribe from this group and all its topics, 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 

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

[Jean-Paul Pelteret]

Maybe, but its not our current logo but rather a new one? ;-)

On Monday, August 28, 2017 at 5:00:12 PM UTC+2, Timo Heister wrote:
>
> My counter: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__files.gitter.im_dealii_itGp_logo.png=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=w-OWsHSFKFvDnpVW9zIrDHHbhcbF69VVZ8_l2TDrs14=7eUaIGiXA633AbVNkMhhGfFdN0m9fwdDWm8xewuKO48=
>  
> 
>  
> nicer font and nicer colors in my opinion. 
>

-- 
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: if else leading to the same path in step 44

[Jean-Paul Pelteret]

Hi Lucas,

So it sounds as if you've already worked out what's happening here. We 
consider 3 cases, namely what to do for newton iteration equal to 0, equal 
to 1, and greater than 1.

For iteration == 0 and iteration == 1, the early return on line 2468 

 
is not satisfied and we have to build some dirichlet constraints. Which 
constraints are build is governed by the iteration number: if it is equal 
to zero, then apply_dirichlet_BC 

 
is set true and we build non-homogeneous constraints (the "if" case). On 
the next visit to this function (iteration == 1) this flag is set to false 
and we build only homogeneous constraints (the "else" case). At subsequent 
iterations we use the early return that I previously mentioned to make no 
further changes to the existing constraint matrix. This is because it is 
already filled with the homogeneous constraints, which is what we want for 
all newton iterations > 0.

Does this make sense?

Regards,
Jean-Paul

On Monday, August 28, 2017 at 4:14:31 PM UTC+2, Lucas Campos wrote:
>
> > This calculation does not happen anyway, because of the early return in 
> line 2466. 
>
> Just a minor correction for the previous sentence: The guard on line 2466 
> will be true only on the second iterations. The else paths will still be 
> taken at least once.
>
> On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:
>>
>> Dear all,
>>
>> First of all, thanks for the great library! I spent the last few days 
>> reading your (very!) extensive 
>> documentation and I think it will be really useful for me in the near 
>> future. 
>>
>> Right now I am struggling a bit on understanding some things on step-44. 
>> Most pressing right 
>> now is that, in Section Solid::make_constraints of the tutorials, we 
>> have 
>>
>> > However, since we are dealing with an iterative Newton method, it 
>> should be noted 
>> > that any displacement constraints should only be specified at the 
>> zeroth iteration 
>> > and subsequently no additional contributions are to be made since the 
>> constraints 
>> > are already exactly satisfied.
>>
>> However, reading the code underneath, the code under the if-else blocks 
>> are the same (around 
>> line 2490 of step-44.cc). That is to say, we would run the same 
>> computation whether the condition 
>> is true or false. This calculation does not happen anyway, because of the 
>> early return in line 2466. 
>> If we disregard this early return, would this code be wrong, or is there 
>> something I am not seeing?
>>
>> Bests,
>> Lucas 
>>
>

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

[Timo Heister]

My counter: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__files.gitter.im_dealii_itGp_logo.png=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=w-OWsHSFKFvDnpVW9zIrDHHbhcbF69VVZ8_l2TDrs14=7eUaIGiXA633AbVNkMhhGfFdN0m9fwdDWm8xewuKO48=
 
nicer font and nicer colors in my opinion.


On Mon, Aug 28, 2017 at 10:38 AM, Wolfgang Bangerth
 wrote:
> On 08/27/2017 05:56 AM, Denis Davydov wrote:
>>
>> Yet another: Courier New Bold, pretty darn close if you ask me. The only
>> difference is rounded ends on I's etc.
>
>
> I like it. Better than Courier (non-New) Bold and the previous font you had.
> Nice work!
>
> Cheers
>  W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
>www:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.math.colostate.edu_-7Ebangerth_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw=8mo-gMNfaOvYNkhGdIwn91CGRUEtJbd_wN5xvkDZclc=9pffXpulcjIxfaymjvJUH_zhkhtDhgo6Cv5-P5u9ZJ8=
> --
> The deal.II project is located at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw=8mo-gMNfaOvYNkhGdIwn91CGRUEtJbd_wN5xvkDZclc=FCQkY8ZVCBW02AY5isQHMT88UbIQBbd7nkhggZ6WkRw=
> For mailing list/forum options, see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_forum_dealii-3Fhl-3Den=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw=8mo-gMNfaOvYNkhGdIwn91CGRUEtJbd_wN5xvkDZclc=uoPvux9itWGEY-KSHqw2u7XFf2zbaGhbxsiRZHX4JJA=
> --- 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://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=R5lvg9JC99XvuTgScgbY_QFS80R7PEA2q0EPwDy7VQw=8mo-gMNfaOvYNkhGdIwn91CGRUEtJbd_wN5xvkDZclc=AWLRo41V0Ax2D57b2XTMvDHtkAlZ7pGZO9juWPPhvhk=
> .



-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
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] Re: Anisotropic fe space

[Wolfgang Bangerth]

On 08/28/2017 06:51 AM, Praveen C wrote:


I am working with Raviart-Thomas spaces. For degree k, the x component of the 
vector field would have degree (k+1) in x variable and degree k in y variable, 
i.e., it is in Q_{k+1,k}. Similarly the y-component is in Q_{k,k+1}. This is 
already provided in FE_RaviartThomasNodal.


I need the test functions for the moments, and these test functions which live 
in Q_{k-1,k} for x-component and in Q_{k,k-1} for y-component.


Since you already found how the FE_RaviartThomas does it, can you not use the 
same approach for your element?


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: if else leading to the same path in step 44

[Lucas Campos]

> This calculation does not happen anyway, because of the early return in 
line 2466. 

Just a minor correction for the previous sentence: The guard on line 2466 
will be true only on the second iterations. The else paths will still be 
taken at least once.

On Monday, 28 August 2017 16:02:01 UTC+2, Lucas Campos wrote:
>
> Dear all,
>
> First of all, thanks for the great library! I spent the last few days 
> reading your (very!) extensive 
> documentation and I think it will be really useful for me in the near 
> future. 
>
> Right now I am struggling a bit on understanding some things on step-44. 
> Most pressing right 
> now is that, in Section Solid::make_constraints of the tutorials, we have 
>
> > However, since we are dealing with an iterative Newton method, it 
> should be noted 
> > that any displacement constraints should only be specified at the zeroth 
> iteration 
> > and subsequently no additional contributions are to be made since the 
> constraints 
> > are already exactly satisfied.
>
> However, reading the code underneath, the code under the if-else blocks 
> are the same (around 
> line 2490 of step-44.cc). That is to say, we would run the same 
> computation whether the condition 
> is true or false. This calculation does not happen anyway, because of the 
> early return in line 2466. 
> If we disregard this early return, would this code be wrong, or is there 
> something I am not seeing?
>
> Bests,
> Lucas 
>

-- 
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] if else leading to the same path in step 44

[Lucas Campos]

Dear all,

First of all, thanks for the great library! I spent the last few days 
reading your (very!) extensive 
documentation and I think it will be really useful for me in the near 
future. 

Right now I am struggling a bit on understanding some things on step-44. 
Most pressing right 
now is that, in Section Solid::make_constraints of the tutorials, we have 

> However, since we are dealing with an iterative Newton method, it should 
be noted 
> that any displacement constraints should only be specified at the zeroth 
iteration 
> and subsequently no additional contributions are to be made since the 
constraints 
> are already exactly satisfied.

However, reading the code underneath, the code under the if-else blocks are 
the same (around 
line 2490 of step-44.cc). That is to say, we would run the same computation 
whether the condition 
is true or false. This calculation does not happen anyway, because of the 
early return in line 2466. 
If we disregard this early return, would this code be wrong, or is there 
something I am not seeing?

Bests,
Lucas 

-- 
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] Re: Anisotropic fe space

[Praveen C]

Hello Jean-Paul

I am working with Raviart-Thomas spaces. For degree k, the x component of
the vector field would have degree (k+1) in x variable and degree k in y
variable, i.e., it is in Q_{k+1,k}. Similarly the y-component is in
Q_{k,k+1}. This is already provided in FE_RaviartThomasNodal.

I need the test functions for the moments, and these test functions which
live in Q_{k-1,k} for x-component and in Q_{k,k-1} for y-component.

Best
praveen

On Mon, Aug 28, 2017 at 6:09 PM, Jean-Paul Pelteret 
wrote:

> Hi Praveen,
>
> I'm a little bit naïve when it comes to these things, but can you not
> achieve this by using an FESystem with each component given by a different
> FE and ensuring that all components are fully coupled?
>
> Regards,
> Jean-Paul
>
>
> On Monday, August 28, 2017 at 12:32:33 PM UTC+2, Praveen C wrote:
>>
>> Hello
>>
>> I want a space of polynomials like Q_{r,s} where the degree is r in one
>> direction and s in another direction. Discontinuous is fine. I know one can
>> construct anisotropic quadrature rules, but I dont see a way to get an fe
>> space. FE_DGQArbitraryNodes seems to need same degree in all directions.
>>
>> Thanks
>> praveen
>>
> --
> 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] Re: Anisotropic fe space

[Jean-Paul Pelteret]

Hi Praveen,

I'm a little bit naïve when it comes to these things, but can you not 
achieve this by using an FESystem with each component given by a different 
FE and ensuring that all components are fully coupled?

Regards,
Jean-Paul

On Monday, August 28, 2017 at 12:32:33 PM UTC+2, Praveen C wrote:
>
> Hello
>
> I want a space of polynomials like Q_{r,s} where the degree is r in one 
> direction and s in another direction. Discontinuous is fine. I know one can 
> construct anisotropic quadrature rules, but I dont see a way to get an fe 
> space. FE_DGQArbitraryNodes seems to need same degree in all directions.
>
> Thanks
> praveen
>

-- 
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] Anisotropic fe space

[Praveen C]

Hello

I want a space of polynomials like Q_{r,s} where the degree is r in one
direction and s in another direction. Discontinuous is fine. I know one can
construct anisotropic quadrature rules, but I dont see a way to get an fe
space. FE_DGQArbitraryNodes seems to need same degree in all directions.

Thanks
praveen

-- 
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] Re: Calling fortran subroutine from my deal.II code

[Praveen C]

Thanks a lot. I will need this in the near future and may save me some
effort from converting fortran to c++.

Best
praveen

On Mon, Aug 21, 2017 at 8:12 PM, Jean-Paul Pelteret 
wrote:

> Hi Praveen,
>
> I know its been a long time since you posted this question, but it caught
> my eye again recently. Matthias has posted an explanation on GitHub
>  as
> to how to work around if you're using an older version of deal.II, or why
> its no longer an issue with the current development version.
>
> Regards,
> Jean-Paul
>
> On Saturday, June 3, 2017 at 10:15:09 PM UTC+2, Praveen C wrote:
>>
>> Dear all
>>
>> I have made changes to CMakeLists.txt
>>
>> set (CMAKE_Fortran_COMPILER "gfortran")
>> set (CMAKE_Fortran_FLAGS_RELEASE "-O2 -m64")
>> set (CMAKE_Fortran_FLAGS_DEBUG   "-O0 -g -m64”)
>>
>> SET(TARGET_SRC
>>   ${TARGET}.cc
>>   kronrod.f90
>>   )
>>
>> PROJECT(${TARGET} CXX Fortran)
>>
>> When I compile, I get this error
>>
>> $ make
>> [ 33%] Building Fortran object CMakeFiles/main.dir/kronrod.f90.o
>> gfortran: error: unrecognized command line option '-Qunused-arguments';
>> did you mean '-Wunused-argument'?
>> make[2]: *** [CMakeFiles/main.dir/kronrod.f90.o] Error 1
>> make[1]: *** [CMakeFiles/main.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> This seems related to clang. How can I fix this ? I see this flag here
>>
>> CMakeFiles/main.dir/flags.make:Fortran_FLAGS = -O3 -g
>> -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOS
>> X.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks
>>  -pedantic -fPIC -Wall -Wextra -Wpointer-arith -Wwrite-strings -Wsynth
>> -Wsign-compare -Wswitch -Woverloaded-virtual  -Qunused-arguments
>> -Wno-unsupported-friend -Wno-unused-parameter -Wno-unused-variable
>> -Wno-undefined-var-template -openmp-simd -std=c++1z -std=c++1z
>> -ftemplate-depth=1024 -Wno-unused-local-typedefs -O0 -ggdb
>> -Wa,--compress-debug-sections
>>
>> Thanks
>> praveen
>>
> --
> 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.