Re: [deal.II] GMesh 1D mesh input error

[Victoria W.]

Hi David, 

Thank you for getting back to me.  I've tried with a .inp mesh produced by 
both gmsh and freeCAD, but I get the same error with my .inp gmsh export 
and when I use the FreeCAD export I have to use the read_abaqus() read in 
method which has been giving me a bad_alloc error message.  I even tried 
writing the 1D mesh from scratch by looking at the tutorial mesh, but that 
also produced a GridIn error.  Do you have any other program suggestions 
for exporting the mesh?  I'm currently installing Salome and looking to try 
that next, but please let me know if there's something else I should be 
using. 

Thank you and all the best, 
Victoria 

On Tuesday, June 23, 2020 at 12:36:01 PM UTC-4, David Wells wrote:
>
> Hi Victoria,
>
> This is definitely a bug with our gmsh reader - the problem is it assigns 
> the boundary ids of 0 to all nodes (since they are associated with a 
> material id of 0), which doesn't make sense since none of the given 
> elements are actually boundary elements. My best guess is that we never 
> tested this code with 1D meshes with nonzero codimension.
>
> The fix to the GMSH code is not immediately obvious. As a temporary 
> workaround, would it be possible for you to convert your mesh to a .inp? 
> That reader seems to work correctly for the dim = 1 spacedim = 2 
> combination.
>
> Best,
> David
>
> On Thu, Jun 18, 2020 at 10:17 AM Victoria W.  > wrote:
>
>> Hi David, 
>>
>> I've been using read_msh() with a version 1 gmsh 1D mesh for the boundary 
>> definition.  Attaching the code snipped of my read_domain() function and 
>> the mesh here.  Thank you for your help.
>>
>> Best, Victoria 
>>
>>
>> On Thursday, June 18, 2020 at 9:35:59 AM UTC-4, David Wells wrote:
>>>
>>> Hi Victoria,
>>>
>>> It's difficult to tell what is going on without seeing some code but 
>>> this looks like a bug in deal.II: that's the correct GridIn function and 
>>> everything should be at the boundary but the assertion still fails for 
>>> reasons that appear to be wrong.
>>>
>>> Can you reproduce the same error if you use that mesh with step-34, 
>>> where you only modify the call to gi.read_ucd() to gi.read_msh()? If so, 
>>> would you please post the mesh to this thread?
>>>
>>> Best,
>>> David
>>>
>>> On Wed, Jun 17, 2020 at 1:28 PM Victoria W.  wrote:
>>>
 Hello, 

 I've been getting the following error message when I try and input a 1D 
 mesh in 2D space for a boundary element method simulation.  I'm working 
 with step-34 tutorial program to model an electric field on an electrode, 
 but I can't get past this mesh input step.  I have tried all of the mesh 
 types that gmsh can output and that dealii will except.  Has anyone seen 
 this before, and does anyone have advice for me?  Thank you to anyone who 
 can help or give advice! 

 -- 
 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/63e62794-13a9-4562-9d60-4568681c077eo%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 dea...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/0c04e288-82dd-4f2b-b873-ebafbe49987co%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/688f383d-d44c-47de-819c-fced52432518o%40googlegroups.com.

Re: [deal.II] GMesh 1D mesh input error

[luca.heltai]

This may be a problem with your physical ids. Can you remove all physical ids 
from the geo file, and try to export a “bare” mesh, without material 
id/boundary id information? 

I currently use vtk for all my needs.

L.

> On 24 Jun 2020, at 14:53, Victoria W.  wrote:
> 
> Hi David, 
> 
> Thank you for getting back to me.  I've tried with a .inp mesh produced by 
> both gmsh and freeCAD, but I get the same error with my .inp gmsh export and 
> when I use the FreeCAD export I have to use the read_abaqus() read in method 
> which has been giving me a bad_alloc error message.  I even tried writing the 
> 1D mesh from scratch by looking at the tutorial mesh, but that also produced 
> a GridIn error.  Do you have any other program suggestions for exporting the 
> mesh?  I'm currently installing Salome and looking to try that next, but 
> please let me know if there's something else I should be using. 
> 
> Thank you and all the best, 
> Victoria 
> 
> On Tuesday, June 23, 2020 at 12:36:01 PM UTC-4, David Wells wrote:
> Hi Victoria,
> 
> This is definitely a bug with our gmsh reader - the problem is it assigns the 
> boundary ids of 0 to all nodes (since they are associated with a material id 
> of 0), which doesn't make sense since none of the given elements are actually 
> boundary elements. My best guess is that we never tested this code with 1D 
> meshes with nonzero codimension.
> 
> The fix to the GMSH code is not immediately obvious. As a temporary 
> workaround, would it be possible for you to convert your mesh to a .inp? That 
> reader seems to work correctly for the dim = 1 spacedim = 2 combination.
> 
> Best,
> David
> 
> On Thu, Jun 18, 2020 at 10:17 AM Victoria W.  wrote:
> Hi David, 
> 
> I've been using read_msh() with a version 1 gmsh 1D mesh for the boundary 
> definition.  Attaching the code snipped of my read_domain() function and the 
> mesh here.  Thank you for your help.
> 
> Best, Victoria 
> 
> 
> On Thursday, June 18, 2020 at 9:35:59 AM UTC-4, David Wells wrote:
> Hi Victoria,
> 
> It's difficult to tell what is going on without seeing some code but this 
> looks like a bug in deal.II: that's the correct GridIn function and 
> everything should be at the boundary but the assertion still fails for 
> reasons that appear to be wrong.
> 
> Can you reproduce the same error if you use that mesh with step-34, where you 
> only modify the call to gi.read_ucd() to gi.read_msh()? If so, would you 
> please post the mesh to this thread?
> 
> Best,
> David
> 
> On Wed, Jun 17, 2020 at 1:28 PM Victoria W.  wrote:
> Hello, 
> 
> I've been getting the following error message when I try and input a 1D mesh 
> in 2D space for a boundary element method simulation.  I'm working with 
> step-34 tutorial program to model an electric field on an electrode, but I 
> can't get past this mesh input step.  I have tried all of the mesh types that 
> gmsh can output and that dealii will except.  Has anyone seen this before, 
> and does anyone have advice for me?  Thank you to anyone who can help or give 
> advice! 
> 
> 
> -- 
> 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/63e62794-13a9-4562-9d60-4568681c077eo%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 dea...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/0c04e288-82dd-4f2b-b873-ebafbe49987co%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/688f383d-d44c-47de-819c-fced52432518o%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 

[deal.II] Re: error while installing dealii

[simon...@gmail.com]

Hi,
In your first sceenshot you can see this error message:

"virtual memory exhausted: Cannot allocate memory"

>From your other screenshots it looks like you are running ubuntu in a 
virtual box. If that is the case, I would expect that increasing the RAM of 
your virtual machine will fix the problem. If I'm not mistaken, at least 
3GB is needed to compile dealii, so maybe < 4GB would be a good choice.

Best,
Simon

On Wednesday, June 24, 2020 at 1:03:16 PM UTC+2 me20...@iittp.ac.in wrote:

>  1. While running *make* command, after 4 to 5 hours i'm getting error 
> like internal compiler error:*killed ( program ccplus ) * or  fatal 
> error:*killed 
> signal terminated program ccplus.*
> 2.while running the command again it is moving 4 to 5% forward in 3 to 4 
> hours  and again getting the same error.
> 3.I'm new to start dealii, can you help me for solving  this issue and 
> here  i'm attaching few  snapshots of this error.
>
>
>

-- 
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/55e531e4-35fe-4680-a802-0372c916d532n%40googlegroups.com.

Re: [deal.II] Re: error while installing dealii

[ME20S001 Bardawal Prakash]

Thanks, I will try with that modification

On Wed, Jun 24, 2020, 5:05 PM simon...@gmail.com 
wrote:

> Hi,
> In your first sceenshot you can see this error message:
>
> "virtual memory exhausted: Cannot allocate memory"
>
> From your other screenshots it looks like you are running ubuntu in a
> virtual box. If that is the case, I would expect that increasing the RAM of
> your virtual machine will fix the problem. If I'm not mistaken, at least
> 3GB is needed to compile dealii, so maybe < 4GB would be a good choice.
>
> Best,
> Simon
>
> On Wednesday, June 24, 2020 at 1:03:16 PM UTC+2 me20...@iittp.ac.in wrote:
>
>>  1. While running *make* command, after 4 to 5 hours i'm getting error
>> like internal compiler error:*killed ( program ccplus ) * or  fatal error
>> :*killed signal terminated program ccplus.*
>> 2.while running the command again it is moving 4 to 5% forward in 3 to 4
>> hours  and again getting the same error.
>> 3.I'm new to start dealii, can you help me for solving  this issue and
>> here  i'm attaching few  snapshots of this error.
>>
>>
>> --
> 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/55e531e4-35fe-4680-a802-0372c916d532n%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/CA%2Bf8FL9J3x8_5zrxkXbC8kXtvs-mkVyOHYMJPQyS3gBmdiMTjg%40mail.gmail.com.

Re: [deal.II] Geometric Conservation Law

[Martin Kronbichler]

Dear Alex,

Great! I would suggest to start by simply adding new code to the 
maybe_update_q_points_Jacobians_... function with the option to turn it 
off or on. Depending on how the final implementation will look like we 
might want to move that to a separate place, but I think it will be less 
repetitive if we use a single place.


Best,
Martin

On 22.06.20 19:59, Alexander Cicchino wrote:

Dear Martin,

Thank you very much! I have been working on making the test case not 
depend on our in house flowsolver's functions.
I think that implementing Eq. 36 the "conservative curl" form would be 
sufficient.
Yes this procedure sounds perfect to me, and I agree with the 
dimension of the object described. I have been going through the 
source code that you sent to familiarize myself with the objects. 
Should I be adding to the function 
maybe_update_q_points_Jacobians_and_grads_tensor or should I create a 
new function for it?


Thank you,
Alex

On Friday, June 19, 2020 at 5:09:14 AM UTC-4, Martin Kronbichler wrote:

Dear Alex,

Great! The first thing we need to know is the equation. I had a
quick look in the paper by Kopriva and I think we want to use
either equation (36) or (37), depending on whether we consider the
conservative or invariant curl form, respectively. In either case,
it appears that we need to do this in a two-step procedure. The
first step is to compute X_l and \nabla_\xi X_m, which in deal.II
speak are the "q_points" and "Jacobians". The implementation in
mapping_q_generic.cc is a bit involved because we have a slow
algorithm (working for arbitrary quadrature rules) and a fast one
for tensor product quadrature rules. Let us consider the fast one
because I think we have most ingredients available, whereas we
would need to fill additional fields for the slow algorithm. The
source code for those parts is here:


https://github.com/dealii/dealii/blob/9e05a87db802ecd073bf7567d77f3491170d84b4/source/fe/mapping_q_generic.cc#L1463-L1592



I skipped the part on the Hessians (second derivative of
transformation) because we won't need them. The important parts
here are the extractions of the positions in line 1554 and the
extraction of the gradients (contravariant transformations) in
line 1575. Those two parts will be the starting point for the
second phase we need to do in addition: According to the algorithm
by Kopriva, we need to define this as the curl of the discrete
interpolation of X_l \nabla_\xi X_m. To get the curl, we need
another round through the SelectEvaluator::evaluate() call in that
function to get the reference-cell gradient of that object, from
which we can then collect the entries of the curl. To call into
evaluate one more time, we also need a new data.shape_info object
that does the collocation evaluation of derivatives. That should
only be two lines that I can show you how and where to add, so let
us not worry about that part now. What is important to understand
first (in terms of index notation vs tensor notation) is the
dimension of the object. I believe that X_l \nabla_\xi X_m is a
rank-two tensor, so it has dim*dim components, and we compute the
gradient that gives us a dim * dim * dim tensor. Taking the curl
in the derivative and inner tensor dimension space, we get rid of
one component and up with a dim * dim tensor as expected. The
final step we need to do is to divide by the determinant of the
Jacobian (contravariant vectors), because the inverse Jacobian in
deal.II does not yet pre-multiply with the determinant.

Does that procedure sound reasonable to you? If yes, we could
start putting together the ingredients. It would be good to have a
mesh (the curvilinear case you were mentioning) where we can test
those formulas.

Best,
Martin

On 17.06.20 18:37, Alexander Cicchino wrote:

Dear Martin,

Thank you for your response. Yes I agree that only some local
computations are necessary to implement the identities.
Yes I would be interested in this feature and trying to implement
it. Do you have any suggestions on where I should start and
overall practices I should follow?

Thank you,
Alex

On Wednesday, June 17, 2020 at 1:19:29 AM UTC-4, Martin
Kronbichler wrote:

Dear Alex,

This has been on my list of things to implement and verify
with deal.II over a range of examples for quite a while, so
I'm glad you bringing the topic up. It is definitely true
that our way to define Jacobians does not take those
identities into account, but I believe we should add support
for them. The nice thing is that only some local computations
are necessary, so having the option to use it 

Re: [deal.II] GMesh 1D mesh input error

[Wolfgang Bangerth]

On 6/24/20 6:53 AM, Victoria W. wrote:


Thank you for getting back to me.  I've tried with a .inp mesh produced by 
both gmsh and freeCAD, but I get the same error with my .inp gmsh export and 
when I use the FreeCAD export I have to use the read_abaqus() read in method 
which has been giving me a bad_alloc error message.
That too sounds like a bug. If you give me the file, I'll investigate that as 
well.


Was the file you sent earlier the one you're trying to read, or was that just 
an example? We know what the offending parts of that file are (all of the type 
15 entities) and we can strip those out by hand.


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/e4938619-dd3f-a5e5-ff0e-23c5be26daeb%40colostate.edu.

[deal.II] New deal.II 9.2.0 package for MAC

[luca.heltai]

Dear All, 

there has been an issue with the deal.II Package which I hope I was able to 
resolve. 

The new mac package is in the same place of the old one

https://github.com/dealii/dealii/releases/download/v9.2.0/dealii-9.2.0.dmg

Would anyone with a mac try it out and tell me if they can run it?

Luca. 

-- 
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/97155645-AFE0-461D-B1D1-1667F4718CFE%40gmail.com.

Re: [deal.II] GMesh 1D mesh input error

[Wolfgang Bangerth]

Victoria,

That was the file I wanted to use - I also tried this 2D mesh in 3D space 
attached.  What is a type 15 entity and why did it cause an error?  The same 
error appeared to be in this .msh file as well.


As mentioned before, it may be possible to remove the "physical entity" things 
in gmsh to avoid the problem.


As for the type 15: If you open the mesh file, it has a section that looks 
like this:


$ELM
58
1 15 0 1 1 1
2 15 0 2 1 2
3 15 0 3 1 3
4 15 0 4 1 4
5 15 0 6 1 5
6 15 0 7 1 6
7 15 0 8 1 7
8 15 0 9 1 8
9 15 0 10 1 9
10 15 0 11 1 10
11 1 0 1 2 10 11
12 1 0 1 2 11 12
13 1 0 1 2 12 13
14 1 0 1 2 13 5
...

The first column is just a counter, the second column is the "type" of the 
object being described. 15 represents individual points, 1 are lines. The 
problem is with these 15s, for which we can't figure out what gmsh wants to 
tell us with these entries. I suspect that if you remove these 10 lines and 
reduce the 58 at the top to 48, that it might actually work. That could give 
you a way forward.


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/9a447045-9e1e-3482-90d1-3cef168be74b%40colostate.edu.

Re: [deal.II] GMesh 1D mesh input error

[Victoria W.]

Hi Wolfgang, 

That was the file I wanted to use - I also tried this 2D mesh in 3D space 
attached.  What is a type 15 entity and why did it cause an error?  The 
same error appeared to be in this .msh file as well. 

Thank you and all the best, 
Victoria 

On Wednesday, June 24, 2020 at 10:57:11 AM UTC-4, Wolfgang Bangerth wrote:
>
> On 6/24/20 6:53 AM, Victoria W. wrote: 
> > 
> > Thank you for getting back to me.  I've tried with a .inp mesh produced 
> by 
> > both gmsh and freeCAD, but I get the same error with my .inp gmsh export 
> and 
> > when I use the FreeCAD export I have to use the read_abaqus() read in 
> method 
> > which has been giving me a bad_alloc error message. 
> That too sounds like a bug. If you give me the file, I'll investigate that 
> as 
> well. 
>
> Was the file you sent earlier the one you're trying to read, or was that 
> just 
> an example? We know what the offending parts of that file are (all of the 
> type 
> 15 entities) and we can strip those out by hand. 
>
> 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/55ed7e95-9952-4a01-8f90-9b0037c8c44ao%40googlegroups.com.


U_electrode_3D.msh
Description: Mesh model

[deal.II] Understanding slightly cryptic warnings from modified Step-52 code

[Krishnakumar Gopalakrishnan]

Hi,

I am solving the basic diffusion equation using the direct method (based on 
Step-52).

I have made the following changes from Step-52 tutorial

1. The domain is now 1D (as opposed to 2D in step-52)
2. We have Neumann BCs on both ends (left NeumannBC = 0.5, right NeumannBC= 
0)
3. Removes the code for MMS validation (i.e. no source term S(t)) so that 
we solve for the unknown field variable, instead of verifying whether the 
pre-formulated analytical solution is retrieved)
4. Sets the absorpotion coefficient, Sigma_a = 0
5. Sets a non-zero initial condition (but a spatially constant value).

The C++ source code & Cmakelists.txt files are attached herewith. The 
solution is indeed correct and is as expected, and I have visualised this 
in Paraview. However, I'd like to understand the compilation warnings. 

Some of them have to do with "unused variables", which are somewhat 
straightforward to get rid of.  But the other warnings which all have the 
string  "required from here" is not so clear to me. 

Can someone please explain what these warnings mean, and what is the best 
practice for refactoring it to avoid such warnings.

Thanks!
Krishna

-- 
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/d6aaa13b-5325-4f4a-9493-23859a5bcb9co%40googlegroups.com.
#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 
#include 

#include 
#include 
#include 
#include 

namespace DiffusionEqn
{
  using namespace dealii;


  template 
  class SolidDiffusion
  {
  public:
SolidDiffusion();

void run();

  private:
void setup_system();

void assemble_system(); // Assembles all components of matrix i.e. those
// multiplying U(t)

// This gives the numerical value of the BC (at left boundary in 1D case)
double get_boundary_neumann_value(const double time) const;

// The 'evaluate_diffusion' function below evaluates RHS of weak form of
// spatially discretised PDE (M^-1  (-Dy-Ay+S + 훽(t) 휓(0)) ). Do not forget
// that this function's return value already accounts for M^-1.

Vector evaluate_diffusion(const double  time,
  const Vector ) const;

void output_results(const double time,
const unsigned int   time_step,
TimeStepping::runge_kutta_method method) const;

unsigned int
embedded_explicit_method(const TimeStepping::runge_kutta_method method,
 const unsigned int n_time_steps,
 const double   initial_time,
 const double   final_time);


const unsigned int fe_degree;

const double diffusion_coefficient;
const double absorption_cross_section;

Triangulation triangulation;

const FE_Q fe;

DoFHandler dof_handler;

AffineConstraints constraint_matrix;

SparsityPattern sparsity_pattern;

SparseMatrix system_matrix; // - \mathcal{D} - \mathcal{A}
SparseMatrix mass_matrix;

SparseDirectUMFPACK inverse_mass_matrix;

Vector solution;

const double b; // length of the hypercube domain in each dimension
  };


  template 
  SolidDiffusion::SolidDiffusion()
: fe_degree(3)
, diffusion_coefficient(1. / 25.) // value of D
// , diffusion_coefficient(1. / 30.) // value of D
, absorption_cross_section(0.) // value of \Sigma_a
, fe(fe_degree)
, dof_handler(triangulation)
, b(5.0)
  {}


  template 
  void SolidDiffusion::setup_system()
  {
dof_handler.distribute_dofs(fe);

constraint_matrix.close();

DynamicSparsityPattern dsp(dof_handler.n_dofs());
DoFTools::make_sparsity_pattern(dof_handler, dsp, constraint_matrix);
sparsity_pattern.copy_from(dsp);

system_matrix.reinit(sparsity_pattern);
mass_matrix.reinit(sparsity_pattern);
solution.reinit(dof_handler.n_dofs());
  }


  template 
  void SolidDiffusion::assemble_system() // Assembles all matrix components
  // i.e. those multiplying U(t)
  {
system_matrix = 0.;
mass_matrix   = 0.;

const QGauss quadrature_formula(fe_degree + 1);

FEValues fe_values(fe,
quadrature_formula,
update_values | update_gradients |
  update_JxW_values);

const unsigned int dofs_per_cell = fe.dofs_per_cell;
const unsigned int n_q_points= quadrature_formula.size();

FullMatrix cell_matrix(dofs_per_cell, 

Re: [deal.II] Understanding slightly cryptic warnings from modified Step-52 code

[Krishnakumar Gopalakrishnan]

Dear Prof Bangerth,

Ah. That now was helpful. Thank you! A scrolling screenful of warnings
which wrap across multiple lines is pretty intimidating for those not so
comfortable with C++.

Hi all,
Is there a tutorial or general online resource that folks here would
recommend for debugging?

Regards,
Krishna


On Wed, 24 Jun 2020 at 23:54, Wolfgang Bangerth 
wrote:

> On 6/24/20 3:14 PM, Krishnakumar Gopalakrishnan wrote:
> > Hi,
> >
> > I am solving the basic diffusion equation using the direct method (based
> on
> > Step-52).
> >
> > I have made the following changes from Step-52 tutorial
> >
> > 1. The domain is now 1D (as opposed to 2D in step-52)
> > 2. We have Neumann BCs on both ends (left NeumannBC = 0.5, right
> NeumannBC= 0)
> > 3. Removes the code for MMS validation (i.e. no source term S(t)) so
> that we
> > solve for the unknown field variable, instead of verifying whether the
> > pre-formulated analytical solution is retrieved)
> > 4. Sets the absorpotion coefficient, Sigma_a = 0
> > 5. Sets a non-zero initial condition (but a spatially constant value).
> >
> > The C++ source code & Cmakelists.txt files are attached herewith. The
> solution
> > is indeed correct and is as expected, and I have visualised this in
> Paraview.
> > However, I'd like to understand the compilation warnings.
> >
> > Some of them have to do with "unused variables", which are somewhat
> > straightforward to get rid of. But the other warnings which all have the
> > string  "required from here" is not so clear to me.
>
> Read the error/warning message in its entirety. For example, the first one
> says
>
> /home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc: In
> instantiation
> of ‘void DiffusionEqn::SolidDiffusion::run() [with int dim = 1]’:
> /home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:441:26:
> required from here
> /home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:420:24:
> warning:
> variable ‘n_steps’ set but not used [-Wunused-but-set-variable]
>   unsigned int   n_steps  = 0;
>  ^~~
>
> If you strip the details, it says:
>
> In instantiation of function b() // i.e., while compiling a()
> required from here   // i.e., we got to a() while
> compiling b()
> warning: variable unused
>
> In other words, the compiler isn't just telling you where (in which
> function
> and line of code) the problem happened, but also *why* it is compiling
> this
> function (because it's called from some other place) and with which
> template
> arguments.
>
> Best
>   W.
>
> >
> > Can someone please explain what these warnings mean, and what is the
> best
> > practice for refactoring it to avoid such warnings.
> >
> > Thanks!
> > Krishna
> >
> > --
> > The deal.II project is located at http://www.dealii.org/
> > <
> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.dealii.org%2F=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568833692=D5TEoM8Dk11JtvV6qM7o79260F%2BztbJpQw5M%2FVghgaU%3D=0
> >
> > For mailing list/forum options, see
> > https://groups.google.com/d/forum/dealii?hl=en
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fforum%2Fdealii%3Fhl%3Den=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568843686=XWXhcdeMs1Poa%2BSLIqCZH73Wh1wqlvqLyz%2BTXB%2FMvBo%3D=0
> >
> > ---
> > 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/d6aaa13b-5325-4f4a-9493-23859a5bcb9co%40googlegroups.com
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fdealii%2Fd6aaa13b-5325-4f4a-9493-23859a5bcb9co%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cfd8a27c47f9a45cc323908d818838c1f%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637286300568843686=4eiKv3%2FUh9%2Bx5zjYczkUfN%2F%2Fwn8M8zpGx%2Fvccf%2FIhjs%3D=0
> >.
>
>
> --
> 
> 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 

Re: [deal.II] Understanding slightly cryptic warnings from modified Step-52 code

[Wolfgang Bangerth]

On 6/24/20 3:14 PM, Krishnakumar Gopalakrishnan wrote:

Hi,

I am solving the basic diffusion equation using the direct method (based on 
Step-52).


I have made the following changes from Step-52 tutorial

1. The domain is now 1D (as opposed to 2D in step-52)
2. We have Neumann BCs on both ends (left NeumannBC = 0.5, right NeumannBC= 0)
3. Removes the code for MMS validation (i.e. no source term S(t)) so that we 
solve for the unknown field variable, instead of verifying whether the 
pre-formulated analytical solution is retrieved)

4. Sets the absorpotion coefficient, Sigma_a = 0
5. Sets a non-zero initial condition (but a spatially constant value).

The C++ source code & Cmakelists.txt files are attached herewith. The solution 
is indeed correct and is as expected, and I have visualised this in Paraview. 
However, I'd like to understand the compilation warnings.


Some of them have to do with "unused variables", which are somewhat 
straightforward to get rid of. But the other warnings which all have the 
string  "required from here" is not so clear to me.


Read the error/warning message in its entirety. For example, the first one says

/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc: In instantiation 
of ‘void DiffusionEqn::SolidDiffusion::run() [with int dim = 1]’:
/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:441:26: 
required from here
/home/bangerth/p/deal.II/1/install/examples/step-1/step-1.cc:420:24: warning: 
variable ‘n_steps’ set but not used [-Wunused-but-set-variable]

 unsigned int   n_steps  = 0;
^~~

If you strip the details, it says:

   In instantiation of function b() // i.e., while compiling a()
   required from here   // i.e., we got to a() while compiling b()
   warning: variable unused

In other words, the compiler isn't just telling you where (in which function 
and line of code) the problem happened, but also *why* it is compiling this 
function (because it's called from some other place) and with which template 
arguments.


Best
 W.



Can someone please explain what these warnings mean, and what is the best 
practice for refactoring it to avoid such warnings.


Thanks!
Krishna

--
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/d6aaa13b-5325-4f4a-9493-23859a5bcb9co%40googlegroups.com 
.



--

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/3d8d3b4d-0fd9-83e0-5457-34dc7e9c612f%40colostate.edu.