[deal.II] Re: DG explicit time integration for linear advection equation with MeshWorker (suggestions)

[vachan potluri]

step-33 does compute interior face integrals twice.

One way I handle this is to attach a cell user index

 Thanks Praveen, this is similar to owner/neighbour concept of OpenFOAM :).


Doug,
Many thanks for the detailed explanations and your code :).

-- 
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/9b315e3b-c862-4e8f-8f78-c572cedc1f82%40googlegroups.com.

Re: [deal.II] Instantiation MappingFEField with hp::DoFHandler

[Doug Shi-Dong]

On Wednesday, September 18, 2019 at 11:28:45 PM UTC-4, Wolfgang Bangerth 
wrote:
>
>
> Doug, 
>
> It does not greatly surprise me that it doesn't compile -- what isn't 
> tested 
> generally doesn't work. 
>

Makes sense. 

We'd of course be very happy to accept any patches to make things work. The 
> general approach to making stuff work is to *always* use hp::FEValues 
> objects 
> to evaluate solution fields. You might want to look at some of the 
> functions 
> in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to 
> see 
> how they work and how the code is written to accommodate both kinds of DoF 
> handler classes. 
>

I think I should be able to get away with always constructing a high-order 
geometric grid for now, but I I'm guessing that it's not going to be the 
only hurdle I encounter with hp. Seems like the same philosophy applies to 
collections e.g. I should *always* use a FECollection of FESystem of 
FiniteElement since that seems to encompass all possibilities.

If I do end up needing those features, should I open an issue and ask to 
get it assigned to myself? And then refer to that issue for pull requests?

A good strategy to implement these kinds of changes is to split things up 
> into 
> a number of incremental changes. Each of these individually doesn't get 
> you to 
> the end point, but fixes one roadblock at a time. I find it much easier to 
> work this way (using many individual pull requests to get to the final 
> goal) 
> than to try and write one monumentally large one, principally because each 
> step individually can be sent through the test suite. (There are 23 tests 
> right now that use this class, so it's reasonably well tested.) If no 
> tests 
> break, then it can't have been so wrong, and one can move on to the next 
> problem. I've definitely implemented things many times that took a 
> sequence of 
> 10 pull requests, each making incremental progress. Writing several new 
> tests 
> in the process is definitely also helpful. I'd suggest you try that 
> approach.  


Thank you for the tip. I did not realise that pull requests could be used 
for "partial" features (as long as they don't break the code). This is my 
first large(ish) project where other students contribute to the code, and 
I'm trying to mimic the forking workflow of open-source projects. Will 
definitely recommend them to do pull requests more often to reduce merge 
conflicts.
 

-- 
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/f59549dd-144c-4687-8cda-3adb141b526f%40googlegroups.com.

Re: [deal.II] Instantiation MappingFEField with hp::DoFHandler

[Wolfgang Bangerth]

Doug,

> I am trying to use MappingFEField to represent my high-order mesh points 
> (which will then be deformed through optimization). Similarly to this thread 
> High order mesh from Gmsh 
> .
>  
> However, I am using hp-finite element and I would expect different element 
> geometric orders to exist for cells with different solution orders.
> 
> I see that MappingFEField is currently only instantiated with DoFHandler, and 
> not hp::DoFHandler, so I tried to add it to the instantiation file 
> "/fe/mapping_fe_field.inst.in". Unfortunately, it seems like the current 
> MappingFEField implementation assumes that the finite element is not a 
> FECollection, etc. and tries to directly operate on it.
> 
> What would be the best way to have different element geometric orders, where 
> I 
> can control the metric degrees of freedom?

It does not greatly surprise me that it doesn't compile -- what isn't tested 
generally doesn't work.

We'd of course be very happy to accept any patches to make things work. The 
general approach to making stuff work is to *always* use hp::FEValues objects 
to evaluate solution fields. You might want to look at some of the functions 
in VectorTools that can either take a ::DoFHandler or hp::DoFHandler to see 
how they work and how the code is written to accommodate both kinds of DoF 
handler classes.

A good strategy to implement these kinds of changes is to split things up into 
a number of incremental changes. Each of these individually doesn't get you to 
the end point, but fixes one roadblock at a time. I find it much easier to 
work this way (using many individual pull requests to get to the final goal) 
than to try and write one monumentally large one, principally because each 
step individually can be sent through the test suite. (There are 23 tests 
right now that use this class, so it's reasonably well tested.) If no tests 
break, then it can't have been so wrong, and one can move on to the next 
problem. I've definitely implemented things many times that took a sequence of 
10 pull requests, each making incremental progress. Writing several new tests 
in the process is definitely also helpful. I'd suggest you try that approach.

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/30bf75d1-4dc2-c725-91b7-2db13325a6dd%40colostate.edu.

[deal.II] Re: Cmake-GUI error

[Gary Roach]

On Tuesday, September 17, 2019 at 3:13:54 PM UTC-7, GaryR wrote:
>
> I keep getting the following error when running cmake-gui.
>
>
> CMake Error at /home/gary/Deal.II/share/deal.II/macros/
> macro_deal_ii_setup_target.cmake:64 (INCLUDE):
>   INCLUDE could not find load file:
>
>
> /home/gary/Deal.II/lib/cmake/deal.II/deal.IITargets.cmake
> Call Stack (most recent call first):
>   /home/gary/Deal.II/share/deal.II/macros/macro_deal_ii_invoke_autopilot.
> cmake:55 (DEAL_II_SETUP_TARGET)
>   CMakeLists.txt:39 (DEAL_II_INVOKE_AUTOPILOT)
>
>
> I've tried mucking my way through the CMakeLists.txt. and the 
> setup_target_.cmake files. I can find the place where the error occurs 
>  but 
> am not familiar enough with the coding to make sense of the problem. 
>
> I am running Debian Buster with a KDE Desktop.
> AMD 4 core processor with 16GB of ram.
> Using Deal.II-9.1.1
> Using Cmake-GUI-3.13.2
> Using Eclipse 2019.6 (4.12.0)
>
> I have Cmake-GUI set up to produce an Eclipse compatible build.
>
> Any help will be sincerely appreciated.
>
> GaryR
>


 Sorry about a couple of things. I mistakenly posted the reply with a 
couple of errors and tried to delete it and re-post. Obviously it didn't 
work. The CDT3 was a typo. I'm taking your advise and trashing the whole 
thing and starting over with no GUI.

Thanks for you timely response

GaryR

On Tuesday, September 17, 2019 at 3:13:54 PM UTC-7, GaryR wrote:
>
> I keep getting the following error when running cmake-gui.
>
>
> CMake Error at /home/gary/Deal.II/share/deal.II/macros/
> macro_deal_ii_setup_target.cmake:64 (INCLUDE):
>   INCLUDE could not find load file:
>
>
> /home/gary/Deal.II/lib/cmake/deal.II/deal.IITargets.cmake
> Call Stack (most recent call first):
>   /home/gary/Deal.II/share/deal.II/macros/macro_deal_ii_invoke_autopilot.
> cmake:55 (DEAL_II_SETUP_TARGET)
>   CMakeLists.txt:39 (DEAL_II_INVOKE_AUTOPILOT)
>
>
> I've tried mucking my way through the CMakeLists.txt. and the 
> setup_target_.cmake files. I can find the place where the error occurs 
>  but 
> am not familiar enough with the coding to make sense of the problem. 
>
> I am running Debian Buster with a KDE Desktop.
> AMD 4 core processor with 16GB of ram.
> Using Deal.II-9.1.1
> Using Cmake-GUI-3.13.2
> Using Eclipse 2019.6 (4.12.0)
>
> I have Cmake-GUI set up to produce an Eclipse compatible build.
>
> Any help will be sincerely appreciated.
>
> GaryR
>
>

-- 
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/92ed3574-5ff6-4fe5-8e37-02f0219849b6%40googlegroups.com.

Re: [deal.II] Re: Cmake-GUI error

[Wolfgang Bangerth]

On 9/18/19 2:10 PM, Gary Roach wrote:
> 
> 
> Thanks for the reply. I'm not sure that this is the correct way to 
> fashion a response. I fnound the forum format a bit confusing.
> 
> For your second question: I am installing Deal.II from 
> dealii-9.1.1.tar.gz. I created a Deal.II directory in my home directory 
> and unzipped the tar file there. I completely stripped out a previous 
> installation because I thought I had misinstalled it.

Are you calling the cmake gui in the directory into which you unpacked 
the sources? You should be calling it in a separate build directory instead.


> I've used the GUI successfully in the past and for the occasional cmake 
> user it is great. I suspect that someone that uses cmake a lot, it might 
> be cumbersome. For use with the tutorials I created a bash file that 
> includes the
> 
> For you first question: The use of "cmake Eclipse CDT3 - Unix Makefiles 
> ."on the command line throws an error, 

Yes. The correct syntax is
   cmake -G"cmake Eclipse CDT3 - Unix Makefiles" .
Note the quotes. (Although for me, it is CDT4. I don't know if CDT3 was 
ever correct.)


> but different from the one thrown 
> by cmake-GUI.  From the CMakeError.log, I found "#error "__AVX__ flag 
> not set, no support for AVX" error. Now my understanding that AVX is 
> associated with the Intel Math Library but not needed for an AMD 
> installation. Not sure why this is happening.

The AVX flags relate to instructions your processor understands. This is 
something that cmake should figure out itself. Did you set any of the 
variables that relate to it in the GUI? That's one of the dangers of 
using the GUI: You get to see all of the internal variables, and might 
have been tempted to change things that aren't meant to be changed.

My recommendation is to just blow the whole directory away and start 
from scratch.

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/f24f096b-3d56-7e9a-f31e-67c9da0d5b40%40colostate.edu.

[deal.II] Re: Cmake-GUI error

[Gary Roach]

On Tuesday, September 17, 2019 at 3:13:54 PM UTC-7, GaryR wrote:
>
> I keep getting the following error when running cmake-gui.
>
>
> CMake Error at /home/gary/Deal.II/share/deal.II/macros/
> macro_deal_ii_setup_target.cmake:64 (INCLUDE):
>   INCLUDE could not find load file:
>
>
> /home/gary/Deal.II/lib/cmake/deal.II/deal.IITargets.cmake
> Call Stack (most recent call first):
>   /home/gary/Deal.II/share/deal.II/macros/macro_deal_ii_invoke_autopilot.
> cmake:55 (DEAL_II_SETUP_TARGET)
>   CMakeLists.txt:39 (DEAL_II_INVOKE_AUTOPILOT)
>
>
> I've tried mucking my way through the CMakeLists.txt. and the 
> setup_target_.cmake files. I can find the place where the error occurs 
>  but 
> am not familiar enough with the coding to make sense of the problem. 
>
> I am running Debian Buster with a KDE Desktop.
> AMD 4 core processor with 16GB of ram.
> Using Deal.II-9.1.1
> Using Cmake-GUI-3.13.2
> Using Eclipse 2019.6 (4.12.0)
>
> I have Cmake-GUI set up to produce an Eclipse compatible build.
>
> Any help will be sincerely appreciated.
>
> GaryR
>


- show quoted text -
Thanks for the reply. 

For your second question: I am installing Deal.II from dealii-9.1.1.tar.gz. 
I created a Deal.II directory in my home directory and unzipped the tar 
file there. I completely stripped out a previous installation because I 
thought I had misinstalled it. 

I've used the GUI successfully in the past and for the occasional cmake 
user it is great. I suspect that someone that uses cmake a lot, it might be 
cumbersome. For use with the tutorials I created a bash file that includes 
the complete command line entry.

For you first question: The use of "cmake Eclipse CDT4 - Unix Makefiles 
."on the command line throws an error, but different from the one thrown by 
cmake-GUI.  From the CMakeError.log, I found "#error "__AVX__ flag not set, 
no support for AVX" error. Now my understanding that AVX is associated with 
the Intel Math Library but not needed for an AMD installation. Not sure why 
this is happening.

I have attached the error log. Hope it helps.

GaryR
- show quoted text -
Attachments (1) 
 

-- 
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/37adadc9-c03d-4b29-84e2-1e477bbe5eab%40googlegroups.com.

[deal.II] Re: Cmake-GUI error

[Gary Roach]

On Tuesday, September 17, 2019 at 3:13:54 PM UTC-7, GaryR wrote:
>
> I keep getting the following error when running cmake-gui.
>
>
> CMake Error at /home/gary/Deal.II/share/deal.II/macros/
> macro_deal_ii_setup_target.cmake:64 (INCLUDE):
>   INCLUDE could not find load file:
>
>
> /home/gary/Deal.II/lib/cmake/deal.II/deal.IITargets.cmake
> Call Stack (most recent call first):
>   /home/gary/Deal.II/share/deal.II/macros/macro_deal_ii_invoke_autopilot.
> cmake:55 (DEAL_II_SETUP_TARGET)
>   CMakeLists.txt:39 (DEAL_II_INVOKE_AUTOPILOT)
>
>
> I've tried mucking my way through the CMakeLists.txt. and the 
> setup_target_.cmake files. I can find the place where the error occurs 
>  but 
> am not familiar enough with the coding to make sense of the problem. 
>
> I am running Debian Buster with a KDE Desktop.
> AMD 4 core processor with 16GB of ram.
> Using Deal.II-9.1.1
> Using Cmake-GUI-3.13.2
> Using Eclipse 2019.6 (4.12.0)
>
> I have Cmake-GUI set up to produce an Eclipse compatible build.
>
> Any help will be sincerely appreciated.
>
> GaryR
>


Thanks for the reply. I'm not sure that this is the correct way to fashion 
a response. I fnound the forum format a bit confusing.

For your second question: I am installing Deal.II from dealii-9.1.1.tar.gz. 
I created a Deal.II directory in my home directory and unzipped the tar 
file there. I completely stripped out a previous installation because I 
thought I had misinstalled it. 

I've used the GUI successfully in the past and for the occasional cmake 
user it is great. I suspect that someone that uses cmake a lot, it might be 
cumbersome. For use with the tutorials I created a bash file that includes 
the

For you first question: The use of "cmake Eclipse CDT3 - Unix Makefiles 
."on the command line throws an error, but different from the one thrown by 
cmake-GUI.  From the CMakeError.log, I found "#error "__AVX__ flag not set, 
no support for AVX" error. Now my understanding that AVX is associated with 
the Intel Math Library but not needed for an AMD installation. Not sure why 
this is happening.

I have attached the error log. Hope it helps.

GaryR

On Tuesday, September 17, 2019 at 3:13:54 PM UTC-7, GaryR wrote:
>
> I keep getting the following error when running cmake-gui.
>
>
> CMake Error at /home/gary/Deal.II/share/deal.II/macros/
> macro_deal_ii_setup_target.cmake:64 (INCLUDE):
>   INCLUDE could not find load file:
>
>
> /home/gary/Deal.II/lib/cmake/deal.II/deal.IITargets.cmake
> Call Stack (most recent call first):
>   /home/gary/Deal.II/share/deal.II/macros/macro_deal_ii_invoke_autopilot.
> cmake:55 (DEAL_II_SETUP_TARGET)
>   CMakeLists.txt:39 (DEAL_II_INVOKE_AUTOPILOT)
>
>
> I've tried mucking my way through the CMakeLists.txt. and the 
> setup_target_.cmake files. I can find the place where the error occurs 
>  but 
> am not familiar enough with the coding to make sense of the problem. 
>
> I am running Debian Buster with a KDE Desktop.
> AMD 4 core processor with 16GB of ram.
> Using Deal.II-9.1.1
> Using Cmake-GUI-3.13.2
> Using Eclipse 2019.6 (4.12.0)
>
> I have Cmake-GUI set up to produce an Eclipse compatible build.
>
> Any help will be sincerely appreciated.
>
> GaryR
>
>

-- 
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/27cdd3dc-8e55-406c-bb90-6c8e19ce5c0e%40googlegroups.com.
Performing C++ SOURCE FILE Test DEAL_II_HAVE_AVX failed with the following 
output:
Change Dir: /home/gary/Deal.II/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_a176d/fast"
/usr/bin/make -f CMakeFiles/cmTC_a176d.dir/build.make 
CMakeFiles/cmTC_a176d.dir/build
make[1]: Entering directory '/home/gary/Deal.II/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_a176d.dir/src.cxx.o
/usr/bin/c++-DDEAL_II_HAVE_AVX   -o CMakeFiles/cmTC_a176d.dir/src.cxx.o -c 
/home/gary/Deal.II/CMakeFiles/CMakeTmp/src.cxx
/home/gary/Deal.II/CMakeFiles/CMakeTmp/src.cxx:3:6: error: #error "__AVX__ flag 
not set, no support for AVX"
 #error "__AVX__ flag not set, no support for AVX"
  ^
/home/gary/Deal.II/CMakeFiles/CMakeTmp/src.cxx: In function ‘int main()’:
/home/gary/Deal.II/CMakeFiles/CMakeTmp/src.cxx:35:9: warning: AVX vector return 
without AVX enabled changes the ABI [-Wpsabi]
   b = _mm256_set1_pd (static_cast(2.25));
   ~~^
make[1]: *** [CMakeFiles/cmTC_a176d.dir/build.make:66: 
CMakeFiles/cmTC_a176d.dir/src.cxx.o] Error 1
make[1]: Leaving directory '/home/gary/Deal.II/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_a176d/fast] Error 2

Return value: 1
Source file was:

#ifndef 

[deal.II] Re: Specifying internal "boundary" conditions

[Bruno Turcksin]

Mélanie,

I am not sure I understand exactly what you want to do but often people who 
want internal boundary conditions, really just want to impose some 
constraints to a few dofs. This can be done using AffineConstraints 
. I 
am sure that you have seen it in the tutorials where it is used to 
constrain hanging nodes and to impose Dirichlet boundary condition. 
Basically, you can create one yourself to impose any constraint you want on 
any dofs.

I hope this help.

Bruno

On Wednesday, September 18, 2019 at 11:34:12 AM UTC-4, Mélanie Gérault 
wrote:
>
> Hi,
>
> I am wondering if anyone has ever implemented/used internal boundary 
> conditions in deal.II. I need to impose displacements inside of a domain. I 
> am assuming that it is feasible with the code, but please let me know if I 
> am wrong.
>
> And in case I need to do it from scratch, I would also appreciate any 
> suggestion you may have.
>
> Thanks a lot!
>
> Mélanie
>

-- 
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/0809d12a-bac9-4f0d-8dc1-430667b90ea3%40googlegroups.com.

Re: [deal.II] Initialization of iterative solver

[Konrad Simon]

>
> Yes, you just set the solution vector to your best guess before you pass 
> it to the solver. But you'll find that in practice, this rarely reduced 
> the number of iterations by any significant amount :-( 
>

Many thanks, Wolfgang. Now, I also saw that in the source code of 
solver_cg.h. I really hoped that would speed up things a bit when solving 
time dependent problems.. Hm. 

Best,
Konrad

-- 
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/c1d3ff11-38c3-4c03-b8a0-5329b3247c27%40googlegroups.com.

Re: [deal.II] Initialization of iterative solver

[Wolfgang Bangerth]

On 9/18/19 9:33 AM, Konrad Simon wrote:
> 
> I have a quick question: Suppose I know a vector that is close to the 
> solution of my linear system. Is there a method to initialize an 
> iterative solver with this vector?

Yes, you just set the solution vector to your best guess before you pass 
it to the solver. But you'll find that in practice, this rarely reduced 
the number of iterations by any significant amount :-(

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/63dae2f8-18cb-68a6-0605-f448bf508e18%40colostate.edu.

[deal.II] Specifying internal "boundary" conditions

[Mélanie Gérault]

Hi,

I am wondering if anyone has ever implemented/used internal boundary 
conditions in deal.II. I need to impose displacements inside of a domain. I 
am assuming that it is feasible with the code, but please let me know if I 
am wrong.

And in case I need to do it from scratch, I would also appreciate any 
suggestion you may have.

Thanks a lot!

Mélanie

-- 
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/109de1d4-828d-4985-8ac6-f723dbaac27e%40googlegroups.com.

[deal.II] Initialization of iterative solver

[Konrad Simon]

Dear deal.ii community,

I have a quick question: Suppose I know a vector that is close to the 
solution of my linear system. Is there a method to initialize an iterative 
solver with this vector?

Best,
Konrad

-- 
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/c9a7e762-bf1b-4ce3-91c1-515610ffdb5b%40googlegroups.com.

Re: [deal.II] Problem warning in eclipse: invalid argument for the distance function

[Brian Zhang]

Thank you very much for your help!

I have deleted my post because I saw Prof. Bangerth answered a similar post 
previously saying the same opinion that the compiler not Eclipse is more 
important.

It is so helpful to receive your answer. It is so important for us beginners to 
get confirmation from experts about something we are not sure.

Thank you again so much for your valuable explanation!

Brian

Sent from my iPhone

> On Sep 17, 2019, at 9:30 PM, Daniel Arndt  wrote:
> 
> Brian,
> 
> The warnings you are seeing come from a static analyzer in Eclipse and not 
> from the compiler. It seems like Eclipse does not have full access to the 
> source code
> or doesn't understand it correctly. E.g., passing a non-const variable to a 
> function that doesn't modify its parameter, is never a problem.
> 
> It is certainly helpful to have a look if these warnings are sensible or not. 
> In this case, I would ignore them though. On the 

Sent from my iPhone

> On Sep 17, 2019, at 9:30 PM, Daniel Arndt  wrote:
> 
> Brian,
> 
> The warnings you are seeing come from a static analyzer in Eclipse and not 
> from the compiler. It seems like Eclipse does not have full access to the 
> source code
> or doesn't understand it correctly. E.g., passing a non-const variable to a 
> function that doesn't modify its parameter, is never a problem.
> 
> It is certainly helpful to have a look if these warnings are sensible or not. 
> In this case, I would ignore them though. On the other hand, I would listen 
> to compiler warnings.
> 
> Best,
> Daniel
> -- 
> 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/CAOYDWbL5qjn6baPKRPBicfW36XGq-z7AL_%3DqCScNpzVkF6k8iQ%40mail.gmail.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/A062B17D-A32F-45E7-9AF6-233B017B9890%40gmail.com.

Re: [deal.II] Re: DG explicit time integration for linear advection equation with MeshWorker (suggestions)

[Praveen C]

> On 18-Sep-2019, at 11:40 AM, Doug  wrote:
> 
> Praveen,
> 
> I did inspire my loops out of your dflo ;). Note that if you use a 
> distributed grid, the user_index() will not be consistent across MPI 
> boundaries. Therefore, you might end up with doubly-counted faces. Here is a 
> [commit](https://github.com/dougshidong/PHiLiP/commit/d0d7e6bd663b0cef032c7f953d2b2dddce4950a7#diff-d2da12f45bddf4e965acafc118ff8366
>  
> )
>  to your if with an if-statement that works for refine/distributed grids.

Thanks a lot for pointing this out. I suppose I never stumbled across this 
issue since I used meshworker in my parallel code.

Best regards
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1582FBD1-6C12-4E28-876A-995BCBB0F227%40gmail.com.

[deal.II] Re: DG explicit time integration for linear advection equation with MeshWorker (suggestions)

[Doug]

Hello Vachan,

Quick note. I'm only suggesting looping yourself because I am not totally 
familiar with MeshWorker. Looping myself exposed the mechanics a bit more 
for me, which I wanted.

I was pointing to step-33 for the loop, not the operators. I don't remember 
seeing a deal.II example implementing deal.II in operator form. 

So, I suggested looping though the cells to compute the operators that are 
not common to all matrices. This is usually the mass matrix if your cells 
are not linear (aka cartesian mesh). The other operators can be made the 
same for all the cells, except for some cofactor Jacobian matrix to 
transfer derivatives and normals from reference space to physical space. If 
you only ever plan on using a cartesian mesh, then all your local matrices 
will be the same. There is no point in assembling a global matrix that will 
operate on your solution. If I were you, I'd take a look at chapter 3 & 6 
of Hesthaven's book where he builds the same local operators that will be 
used on each cell. Therefore, you wouldn't have an array of differentiation 
matrices. Just one small differentiation matrix that applies to all cells. 
Feel free to look at how I do the [mass matrix](
https://github.com/dougshidong/PHiLiP/blob/master/src/dg/dg.cpp#L752)

Step-33 is CG by the way, therefore, two cells at the same level (no 
hanging nodes) don't need to be added to the residual. Therefore, they 
don't show that case. Feel free to look at my [loops](
https://github.com/dougshidong/PHiLiP/blob/master/src/dg/dg.cpp#L246), 
where I loop over all the cells, and all the faces. For internal faces, 
only one cell will be responsible to evaluate the flux and add it to both 
sides.

If someone wants to chime in with a better way to loop over all the faces 
just once, I would love to know about it too.

You can also keep on eye out on the code I linked. It currently does not 
pre-compute the operators, but it's only a matter of moving the loops out 
to pre-processing. 

Praveen,

I did inspire my loops out of your dflo ;). Note that if you use a 
distributed grid, the user_index() will not be consistent across MPI 
boundaries. Therefore, you might end up with doubly-counted faces. Here is 
a [commit](
https://github.com/dougshidong/PHiLiP/commit/d0d7e6bd663b0cef032c7f953d2b2dddce4950a7#diff-d2da12f45bddf4e965acafc118ff8366)
 to 
your if with an if-statement that works for refine/distributed grids.

On Wednesday, September 18, 2019 at 12:33:43 AM UTC-4, vachan potluri wrote:
>
> Doug and Praveen,
>
> Thanks for your answers. I had a look at step-33. As far as I understand, 
> although the looping through cells is not through MeshWorker, the assembly 
> is still global! So, for a non-cartesian mesh, I think you are suggesting 
> using such a loop over all cells to calculate local matrices. Will these 
> cell-local matrices stored as an array of matrices in the conservation law 
> class?
>
> I now have one more question. In assemble_face_term function of step-33, 
> the normal numerical flux is calculated. This function is called for every 
> cell-neighbor pair from the assemble_system function. This means, if I am 
> not wrong, at every interior face quadrature point, the numerical flux is 
> calculated twice. This might be very costly. Is there a way to avoid this? 
> One can probably force only one cell to calculate numerical flux at a face 
> based on the face normal's orientation. But then how can we communicate the 
> calculated flux to the other cell. Or even better, is it possible to loop 
> over faces? We could then add contributions to both the cells sharing this 
> face without double computation.
>
> Thanks again!
>

-- 
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/6f1ae5d3-a150-457a-8a6d-fa393910b15e%40googlegroups.com.