Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

[Magdalini Ntetsika]

I see. Thank you Daniel!

Best,
Magda

On Thursday, March 5, 2020 at 1:39:26 PM UTC-8, Daniel Arndt wrote:
>
> Magdalini,
>
> The problem only appears with inhomogeneous boundary conditions, but 
> periodic boundary conditions don't set any inhomogeneity.
>
> Best,
> Daniel
>
> Am Do., 5. März 2020 um 16:13 Uhr schrieb Magdalini Ntetsika <
> ntet...@berkeley.edu >:
>
>> Hi Wolfgang,
>>
>> thank you for the prompt reply. I see, I'll look up both. But I have a 
>> quick question: what if I have periodic boundary conditions all around my 
>> domain? It seems to be working in that case, even if the boundary values 
>> are nonzero, I get to have the correct system_rhs vector. I guess will need 
>> first to watch the topic on Dirichlet Boundary conditions to understand 
>> better, but it will be very helpful if I could get some feedback on that 
>> specific observation from you.
>>
>> Best,
>> Magda
>>
>> On Thursday, March 5, 2020 at 9:41:11 AM UTC-8, Wolfgang Bangerth wrote:
>>>
>>> On 3/5/20 9:24 AM, Magdalini Ntetsika wrote: 
>>> > 
>>> > but I don't seem to get the same *system_rhs *when 
>>> > *assemble_system=false* as when *assemble_system=true*. To be more 
>>> > specific, it seems that there is something wrong with how 
>>> > constraints.distribute_local_to_global(local_rhs, local_dof_indices, 
>>> > system_rhs) creates the system_rhs from local_rhs and 
>>> > local_dofs_indices. I don't change anything about constraints etc 
>>> > throughout the time steps since I set those things up at the very 
>>> > beginning and then I just run several times without updating anything. 
>>> > Any idea about what the problem could be? 
>>>
>>> Magdalini, 
>>> it's not in the function you point to, but in your understanding. In 
>>> order to compute the correct values of the right hand side when you have 
>>> non-zero constraints (e.g., when you have nonzer boundary values), the 
>>> function you call needs to have access to the matrix elements. 
>>>
>>> The issue is a bit complicated to understand, but you may want to look 
>>> up the video lectures on the topic of Dirichlet boundary conditions. 
>>>
>>> As for your case, take a look at step-26, which deals with exactly this 
>>> problem by building the matrix only once, but then using it for several 
>>> time steps. 
>>>
>>> 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 dea...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/a320a562-6800-4650-871f-83a5eff9b79a%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1964a904-4c6e-4ca6-8ba7-8c7a2c10769d%40googlegroups.com.

Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

[Daniel Arndt]

Magdalini,

The problem only appears with inhomogeneous boundary conditions, but
periodic boundary conditions don't set any inhomogeneity.

Best,
Daniel

Am Do., 5. März 2020 um 16:13 Uhr schrieb Magdalini Ntetsika <
ntets...@berkeley.edu>:

> Hi Wolfgang,
>
> thank you for the prompt reply. I see, I'll look up both. But I have a
> quick question: what if I have periodic boundary conditions all around my
> domain? It seems to be working in that case, even if the boundary values
> are nonzero, I get to have the correct system_rhs vector. I guess will need
> first to watch the topic on Dirichlet Boundary conditions to understand
> better, but it will be very helpful if I could get some feedback on that
> specific observation from you.
>
> Best,
> Magda
>
> On Thursday, March 5, 2020 at 9:41:11 AM UTC-8, Wolfgang Bangerth wrote:
>>
>> On 3/5/20 9:24 AM, Magdalini Ntetsika wrote:
>> >
>> > but I don't seem to get the same *system_rhs *when
>> > *assemble_system=false* as when *assemble_system=true*. To be more
>> > specific, it seems that there is something wrong with how
>> > constraints.distribute_local_to_global(local_rhs, local_dof_indices,
>> > system_rhs) creates the system_rhs from local_rhs and
>> > local_dofs_indices. I don't change anything about constraints etc
>> > throughout the time steps since I set those things up at the very
>> > beginning and then I just run several times without updating anything.
>> > Any idea about what the problem could be?
>>
>> Magdalini,
>> it's not in the function you point to, but in your understanding. In
>> order to compute the correct values of the right hand side when you have
>> non-zero constraints (e.g., when you have nonzer boundary values), the
>> function you call needs to have access to the matrix elements.
>>
>> The issue is a bit complicated to understand, but you may want to look
>> up the video lectures on the topic of Dirichlet boundary conditions.
>>
>> As for your case, take a look at step-26, which deals with exactly this
>> problem by building the matrix only once, but then using it for several
>> time steps.
>>
>> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/a320a562-6800-4650-871f-83a5eff9b79a%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAOYDWbKXD1Oijy5YKX71b7vWeT7_%3Dzcu58gK_Es5BYBsHiZc-w%40mail.gmail.com.

Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

[Magdalini Ntetsika]

Hi Wolfgang,

thank you for the prompt reply. I see, I'll look up both. But I have a 
quick question: what if I have periodic boundary conditions all around my 
domain? It seems to be working in that case, even if the boundary values 
are nonzero, I get to have the correct system_rhs vector. I guess will need 
first to watch the topic on Dirichlet Boundary conditions to understand 
better, but it will be very helpful if I could get some feedback on that 
specific observation from you.

Best,
Magda

On Thursday, March 5, 2020 at 9:41:11 AM UTC-8, Wolfgang Bangerth wrote:
>
> On 3/5/20 9:24 AM, Magdalini Ntetsika wrote: 
> > 
> > but I don't seem to get the same *system_rhs *when 
> > *assemble_system=false* as when *assemble_system=true*. To be more 
> > specific, it seems that there is something wrong with how 
> > constraints.distribute_local_to_global(local_rhs, local_dof_indices, 
> > system_rhs) creates the system_rhs from local_rhs and 
> > local_dofs_indices. I don't change anything about constraints etc 
> > throughout the time steps since I set those things up at the very 
> > beginning and then I just run several times without updating anything. 
> > Any idea about what the problem could be? 
>
> Magdalini, 
> it's not in the function you point to, but in your understanding. In 
> order to compute the correct values of the right hand side when you have 
> non-zero constraints (e.g., when you have nonzer boundary values), the 
> function you call needs to have access to the matrix elements. 
>
> The issue is a bit complicated to understand, but you may want to look 
> up the video lectures on the topic of Dirichlet boundary conditions. 
>
> As for your case, take a look at step-26, which deals with exactly this 
> problem by building the matrix only once, but then using it for several 
> time steps. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/a320a562-6800-4650-871f-83a5eff9b79a%40googlegroups.com.

Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

[Wolfgang Bangerth]

On 3/5/20 9:24 AM, Magdalini Ntetsika wrote:


but I don't seem to get the same *system_rhs *when 
*assemble_system=false* as when *assemble_system=true*. To be more 
specific, it seems that there is something wrong with how 
constraints.distribute_local_to_global(local_rhs, local_dof_indices, 
system_rhs) creates the system_rhs from local_rhs and 
local_dofs_indices. I don't change anything about constraints etc 
throughout the time steps since I set those things up at the very 
beginning and then I just run several times without updating anything. 
Any idea about what the problem could be?


Magdalini,
it's not in the function you point to, but in your understanding. In 
order to compute the correct values of the right hand side when you have 
non-zero constraints (e.g., when you have nonzer boundary values), the 
function you call needs to have access to the matrix elements.


The issue is a bit complicated to understand, but you may want to look 
up the video lectures on the topic of Dirichlet boundary conditions.


As for your case, take a look at step-26, which deals with exactly this 
problem by building the matrix only once, but then using it for several 
time steps.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/499c0528-adc8-00e4-f331-a50704704940%40colostate.edu.

[deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

[Magdalini Ntetsika]

Hi,

I want to assemble my system matrix only once since it doesn't change 
throughout the time steps. For that my code is similar to step-57:

if (assemble_matrix){
 constraints.distribute_local_to_global(local_matrix, local_rhs, 
local_dof_indices, system_matrix, system_rhs);
}
else{
constraints.distribute_local_to_global(local_rhs, local_dof_indices, 
system_rhs);
}

but I don't seem to get the same *system_rhs *when *assemble_system=false* 
as when *assemble_system=true*. To be more specific, it seems that there is 
something wrong with how constraints.distribute_local_to_global(local_rhs, 
local_dof_indices, system_rhs) creates the system_rhs from local_rhs and 
local_dofs_indices. I don't change anything about constraints etc 
throughout the time steps since I set those things up at the very beginning 
and then I just run several times without updating anything. Any idea about 
what the problem could be?

Best,
Magda

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/174a9f9e-491a-47f2-9e36-d737bca51d13%40googlegroups.com.

Re: [deal.II] necessity of learning java coding

[Wolfgang Bangerth]

On 3/5/20 4:54 AM, arun gk wrote:


I am a Postgraduate with 4+ years of experience in Mechanical Software such 
Ansys, Abaqus, Hypermesh etc.

Recently I got a job offer from a fintech company specialized in online 
payments.
Only thing they asked me to do is to learn Coding (Java, SQL etc.)

My Question is,

In spite of knowing the above mentioned basic mechanical Software, will 
learning Java help me to shine in Software Development field ?.


Well, that's not really a deal.II-related question, but I'll answer it anyway: 
In the financial service, everything is Java. So if that's where you want to 
work, yes, learning and knowing Java is a large plus.


It's just like in data sciences you need to know R. And in computational 
science you need to know C++. Different fields different traditions.


As a general rule, speaking many programming languages also makes you a better 
programmer.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/7768a3f8-c97f-2806-5346-fc8e6e717e43%40colostate.edu.

[deal.II] necessity of learning java coding

[arun gk]

Respected members,

I am a Postgraduate with 4+ years of experience in Mechanical Software such 
Ansys, Abaqus, Hypermesh etc.
Recently I got a job offer from a fintech company specialized in online 
payments.
Only thing they asked me to do is to learn Coding (Java, SQL etc.)

My Question is,

In spite of knowing the above mentioned basic mechanical Software, will 
learning Java help me to shine in Software Development field ?.

Kindly do reply for this mail.  

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/14edf60c-50f1-404a-bce0-dce0cc61127f%40googlegroups.com.

[deal.II] discrepancy in step-44 material model between implementation and formula.

[navneet roshan]

Dear delii members

While modifying the material model in the step-44.cc, implementation of the
function *get_Jc_vol(). *I found the implementation in the code is
different than the formula provided. The worse part is that the solution
stops converging after correcting the implementation. I will be really
grateful if some one can hint me as, I am stuck between convergence and
divergence of material models from quite some time.

   The given implementation is:
   SymmetricTensor<4, dim>

get_Jc_vol() const
{
return p_tilde * det_F *
(Physics::Elasticity::StandardTensors::IxI

-
(2.0 * Physics::Elasticity::StandardTensors::S

))
}

The implementation as per formula, should have been:

 SymmetricTensor<4, dim> get_Jc_vol() const
 {
 return det_F  * (  (get_dPsi_vol_dJ() +
det_F*get_d2Psi_vol_dJ2() )
   *Physics::Elasticity::StandardTensors::IxI
  - (2.0 * get_dPsi_vol_dJ() *
Physics::Elasticity::StandardTensors::S) );
}

Thank you,

Regards,
Navneet R

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/CAK9McD0Rm7GotVhecV4%3D2ExxGcZPUtPLVQNVi652skkXYG0mOQ%40mail.gmail.com.