Re: [deal.II] Boundary conditions on components in with FESystem

2020-11-08 Thread Wolfgang Bangerth 

On 11/6/20 10:11 AM, Konrad Simon wrote:


I have a code version in which I am using a FESystem (3d) composed of three 
elements: FE_Nedelec (w), FE_RaviartThomas (u) and DGQ (p).


The code compiles fine but gives unreasonable results and I do not see what I 
am doing wrong or what I forgot.
Instead of trying to divine what the code is doing (and apparently doing 
wrong), let me outline the way I would think about this:


* You say that the results are "unreasonable". That can mean a lot of 
different things. Try to explain for yourself what you see, and understand 
what part looks wrong. Is it the boundary values? That is, does the solution 
you see visualized violate the boundary conditions you wanted to impose? If 
so, that's clearly an area of concern.


* If the solution does seem to satisfy the boundary conditions, but is wrong 
in the interior of the domain, then the problem lies elsewhere.


* In any case, if you can't find where things go wrong, try solving a 
decoupled problem where you assemble a matrix in which each variable appears 
in only one equation. This helps you identify *which boundary condition*, or 
*which equation* is wrongly implemented.


In the end, debugging comes down to generating hypotheses about what could be 
wrong, and then testing each hypothesis in detail until you can confirm or 
deny that your hypothesis is the cause of the problem. Creating hypotheses 
often comes down to carefully looking at the solution and verbalizing for 
yourself what you see and how it (qualitatively) differs from what you expect. 
In practice, this often leads to faster ways to debugging than randomly poking 
at individual pieces of your code.


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/e41c1a04-c857-ab3f-e2d8-6c9178fdaeb6%40colostate.edu.

Re: [deal.II] Use Gmsh to import external grid calculation elasticity problem

2020-11-08 Thread Wolfgang Bangerth 

On 11/7/20 4:16 AM, Nick Wang wrote:
I have another question to ask, whether point load can be applied in deal.ii, 
according to the steps I have learned, I can only apply range load temporarily


You can use the function VectorTools::create_point_source_vector()
https://www.dealii.org/7.3.0/doxygen/deal.II/namespaceVectorTools.html#ad03b858b1a3b59003a76f6224e67efc7
You might also want to look into the implementation of the function if you 
need to implement a slightly different situation.


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/d46564ef-6931-9ec1-ba69-0c57ad7f4011%40colostate.edu.

[deal.II] Re: Some changes in arpack.h (Functionality to compute only eigenvalues)

2020-11-08 Thread Animesh Rastogi IIT Gandhinagar 
Thank you Bruno, I was able to change the source code accordingly. I 
reinstalled dealii and it worked fine!

Thanks again!

Animesh

On Friday, November 6, 2020 at 3:55:29 AM UTC+5:30 bruno.t...@gmail.com 
wrote:

> Animesh,
>
> On Thursday, November 5, 2020 at 1:11:33 PM UTC-5 
> animesh...@alumni.iitgn.ac.in wrote:
>
>> However, I have no way of passing it as a parameter to the solver 
>> 
>>  
>> function. I was planning to edit the header file *arpack.h* 
>> 
>>  
>> accordingly which is inside the */usr/local/include/deal.II/lac* to have 
>> that functionality. I was actually thinking of passing the flag "rvec" as 
>> an argument to the function solve 
>> .
>>  
>> I was wondering if I change the permission of the file to write mode, edit 
>> it and save it, would I be able to run my code inside the examples folder. 
>> Or do I need to take care of something else while and after editing that 
>> headerfile?
>>
> You should change the source code and reinstall deal.II. I would do what 
> you propose only if you cannot compile deal.II on that machine. It might 
> work in this particular case but I really advise you against it.
>
> Best,
>
> Bruno
>  
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/92ecd7e0-b47b-4d7a-8009-eb31eadaae37n%40googlegroups.com.