Re: [deal.II] Re: Pressure-correction scheme: Behaviour of the H1 norm on the Taylor-Green vortex

[blais...@gmail.com]

Hello Jose,
I hope you are well.
I was wondering if you had managed to get your code on github or any 
sharing service? I would be really interested in comparing how it behaves 
with monolothic FEM approaches. This is something that is very relevant to 
our research (and on which I would be glad to collaborate :) )


On Saturday, October 24, 2020 at 6:23:55 a.m. UTC-4 jose.a...@gmail.com 
wrote:

> Hello Wolfgang, Marthin, Bruno, Richard and Timo,
>  
>
>> 'm not entirely clear about what your question is. Are you seeing 
>> convergence 
>> rates that are too low or too large? It is not uncommon to have cases 
>> where a 
>> scheme converges too fast (the convergence rate is too large); this is 
>> typically the case because the solution has a symmetry.
>>
>> Best
>>   W.
>
>
> Apologies for not explaining myself clearer. I will try it again:
> From my understanding, the lowest bound of the error on each norm is set 
> either by the spatial or the temporal discretization. I was kind of 
> expecting that the L2- and H1-Norms share a similar spatial and time 
> dependence, i.e. that each field reaches its lowest bound simultaneously, 
> and that they do so with a similar convergence rate evolution. Stated 
> differently, they start with an order of convergence which remains constant 
> for a given time step range. After reaching a small time step size, the 
> convergence order tends to zero as the lowest bound of the error is reached.
> From the tests' results I can see that H1-Norm of the pressure has a 
> considerably stronger spatial dependence than the velocity, as it reaches 
> its lowest bound while the velocity still has a constant convergence order. 
> This behaviour is also seen in the L2- and Linfty-Norm but in a much more 
> milder scale, as seen in the spatial convergence test. My question is if 
> this stronger spatial dependency of the pressure is problem dependent or if 
> it is intrinsic to the pressure-correction scheme.
>
> While I have not experimented in detail with the step-35 program, we have 
>> done extensive studies on similar problems in 
>> https://doi.org/10.1016/j.jcp.2017.09.031 (or 
>> https://arxiv.org/abs/1706.09252 for an earlier preprint version of the 
>> same manuscript) including the pressure correction scheme. While the 
>> spatial discretization is DG where some of the issues are , the experience 
>> from our experiments suggests that the pressure correction scheem should 
>> not behave too differently from other time discretization schemes with 
>> similar ingredients (say BDF-2 on the fully coupled scheme). In other 
>> words, I would expect second order convergence in the pressure for 
>> Taylor-Hood elements. I should note that there are some subtle issues with 
>> boundary conditions in projection schemes, so I cannot exclude some hidden 
>> problems with the step-35 implementation or the way you set up the 
>> experiments.
>>
>> Best,
>> Martin
>>
> Thanks for the manuscript, there I notice that the results shown are those 
> of the behaviour of the L2-Norm. My finite element implementation behaves 
> similarly in the L2-Norm to the convergence rates in your paper (BFD2 leads 
> to a 2nd order convergence on both velocity and, for the most part, on 
> pressure). Did you also analyse the H1-Norm by any chance? There is where I 
> see the stronger spatial dependency of the pressure.
> On another note, it caught my eye that you split the Neumann boundary 
> conditions. I have not done tests with them yet, but what is the benefit of 
> doing this or why is it necessary? Furthermore, my next step would be the 
> DFG 2D-2 benchmark. There, you computed the traction force using the 
> symmetric gradient instead of the normal gradient. While your formulation 
> would be for me the correct formulation, as the stress tensor is so 
> defined, on the benchmark papers they use the normal gradient. This has 
> caused me some confusion, as to which formulation should I implement for 
> the benchmark.
>
> Hello Jose,
>> I wish I could help, but I second Wolfgang's question.
>> Is your code available somewhere? I would be glad to take a look at it 
>> and compare the solutions for the same problems using different 
>> formulations. I would expect that if you fix the issue with boundary 
>> conditions (those described in the Guermond paper, that is the  "pressure 
>> boundary layer") then you would recover exactly what you should get with 
>> traditional schemes using Taylor-Hood element (as Martin discussed).
>>
>
> I tried reformulating the question above. Hopefully it is clearer now. I 
> will clean the code up and get back to you. The pressure-correction scheme 
> I am using is the incremental rotational, which has the smallest error 
> caused due to the boundary layer. Could the boundary layer in this case 
> still cause such a strong influence? 
>
> if the velocity error you have is low enough, the somewhat 
>> time-independent PPE you solve given that velocity,
>> you 

Re: [deal.II] Lapack Link Problem

[Aaditya Lakshmanan]

Hi,
   I installed deal.II on my windows subsystem for linux(WSL) this morning 
with OpenBLAS which I installed as follows :

 *sudo apt install libblas3*  # it will be *sudo apt-get install libblas3* 
if you have a separate ubuntu installation

after which deal.II(version 9.3.0-pre) installed just fine for me(in the 
*cmake* line I did specify *-DDEAL_II_WITH_LAPACK=ON*). You might want to 
remove all existing installations of BLAS/LAPACK(using *sudo apt remove*) 
and install what is minimally required. If *cmake* executes fine and uses 
*libblas3* then in the *detailed.log* file the line corresponding to LAPACK 
libraries should read :

*#LAPACK_LIBRARIES = /usr/lib/x86_64-linux-gnu/libopenblas.so*

the above line may include additional keywords separated by semi-colons, 
but the */usr/lib/x86_64-linux-gnu/libopenblas.so *should be a part of the 
*LAPACK_LIBRARIES 
*environment variable.

Best,
Aaditya

On Tuesday, October 27, 2020 at 10:24:13 PM UTC-4 hkch...@gmail.com wrote:

> Hello all,
> When I want to compile dealii with lapack , 
> whatever how I set the dir of lapck, the CMAKE can;t find the lapack.(I 
> also set the lapack_dir in ccmake) error is following:
>
> -
>
>   Could not find the lapack library!
>
>   Please ensure that a suitable lapack library is installed on your 
> computer.
>
>   If the library is not at a default location, either provide some hints 
> for
>   autodetection,
>
>   $ LAPACK_DIR="..." cmake <...>
>   $ cmake -DLAPACK_DIR="..." <...>
>
>   or set the relevant variables by hand in ccmake.
>
>
> -
> I run the command at shell:
>
> sudo find / -name "lapack"
>
> I get the path as follow:
>
> /usr/lib/x86_64-linux-gnu/lapack
>
> /home/chen/.local/lapack
>
> first lapack maybe the version that installed through
>
> sudo apt-get install libblas-dev liblapack-dev
>
> second lapack is the version compiled by myself
> there are some share lib in the dir:
>
> :/usr/lib/x86_64-linux-gnu/lapack$ ls
> liblapack.a  liblapack.so  liblapack.so.3  liblapack.so.3.9.0
> ~/.local/lapack$ ls
> cmake  libblas.a  liblapack.a  pkgconfig
>
> Could anyone help me?
> Best,
> Chen
>

-- 
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/4970a9dc-d584-47f4-b456-a7f5532dc3een%40googlegroups.com.