Re: [deal.II] advection equation weak form in tutorial 9

[Wolfgang Bangerth]

Jaekwang,

I am little bit confused by weak form for advection problem written in step-9 
tutorial


in the its tutorial, in the middle of the line, it says that...

I am little bit unsure the red-marked form,


I think you forgot the formula.


 From the whole boundary integral, we put inflow case, to the right hand side, 
and remaining part on left-hand-side is cases other than inflow condition


so I thought, this should be..




the left hand side term is boundary that is not inflow case...


I'm not entirely sure I understand your question, but you arrive at the weak 
formulation by

* taking the original PDE, multiplying it with the modified test functions,
  and integrating by parts
* on both sides of the equations, add the term
(beta.n v_h, u_h)_{inflow boundary}
* on the right hand side, replace u_h by g_h on the inflow boundary part

The key step that may not have been obvious is that in the second step, we add 
the same thing to both sides of the equation. The equation therefore must 
remain the same.


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.
For more options, visit https://groups.google.com/d/optout.

Re: [dealii-developers] Retiring the deal.II developer mailing list

[Wolfgang Bangerth]

On 08/14/2017 11:36 AM, Timo Heister wrote:
We decided to retire the "deal.II developer mailing list" in favor of the 
"deal.II User Group".


For context, it's not that there is no longer a need for discussing technical 
issues. It's more that technical issues seem to be discussed on github issues 
under

  https://github.com/dealii/dealii/issues
these days. The advantage of that forum is that it integrates discussion about 
concrete issues with the patches that are then submitted via github at

  https://github.com/dealii/dealii/pulls

Best
 W.

--

Wolfgang Bangerth  email: bange...@colostate.edu
   www: http://www.math.colostate.edu/~bangerth/

--
You received this message because you are subscribed to the Google Groups "deal.II 
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] advection equation weak form in tutorial 9

[Jaekwang Kim]

Hi, all 

I am little bit confused by weak form for advection problem written in 
step-9 tutorial 

in the its tutorial, in the middle of the line, it says that... 

I am little bit unsure the red-marked form, 

>From the whole boundary integral, we put inflow case, to the right hand 
side, and remaining part on left-hand-side is cases other than inflow 
condition 

so I thought, this should be.. 


 

the left hand side term is boundary that is not inflow case... 

I saw similar expression, in Dr. Bangerth video lecture 31, on hyperbolic 
equation, here his weak form also marked 'not inflow boundary' remaining in 
left hand side and inflow case, with boundary value description went to RHS 


. I am not sure i am just confusing some of indication... .. 


thanks !









This is a point we made in the introduction of step-3 
. There, we argued 
that to avoid this very kind of problem, one should get in the habit of 
always multiplying with test functions *from the left* instead of from the 
right to obtain the correct matrix right away. In order to obtain the form 
of the linear system that we need, it is therefore best to rewrite the weak 
formulation to 

(vh+δβ⋅∇vh,β⋅∇uh)Ω*−(β⋅nvh,uh**)**∂**Ω**−*=(vh+δβ⋅∇vh,f)Ω−(β⋅nvh,g)∂Ω−

and then to obtain

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[dealii-developers] Retiring the deal.II developer mailing list

[Timo Heister]

We decided to retire the "deal.II developer mailing list" in favor of the 
"deal.II User Group".

Please subscribe and post there in the future: 
 https://groups.google.com/forum/#!forum/dealii

This group will be locked soon. Get in contact with me if you have any 
concerns.

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Using the solution from one problem as a boundary condition in another problem with matching mesh on the boundary

[vladislav . dealii]

Thank you, Kristjan.

Both links are helpful.   



On Monday, August 14, 2017 at 1:10:36 PM UTC+2, krei wrote:
>
> Hi Vladislav,
>
> You can take a look at my project here: 
> https://github.com/eimrek/dealii-field-currents-heating, perhaps it's 
> useful. In currents_and_heating.h/.cc files I use a map between vacuum and 
> metal face cells to evaluate boundary condition from one domain in the 
> other. Note that in my case the coupling is only one-directional.
>
> Mike's repository is here: https://github.com/mdh266/PECS, this might be 
> also useful for you.
>
> Best,
> Kristjan
>
> On Mon, Aug 14, 2017 at 11:17 AM,  
> wrote:
>
>> Hello, Mike,
>>
>> I have a similar problem like you. I have two PDEs in separate domains 
>> coupled through an interface. I have also tried to solve this using 
>> step-46.However, my code haven't produced the correct solution in my test 
>> case. Thus, I am very interested to try new approaches, especially how you 
>> have solved the problem using two different meshes (which of course fit on 
>> the interface). Could you send me a code snippet showing how you deal with 
>> the interface term and the vertices on the different meshes? It would be 
>> very helpful. Your idea using std::map makes sense to me, however I still 
>> can not really imagine how everything works together in the code.
>>
>> Best,  
>> Vladislav
>>
>>
>> On Tuesday, August 23, 2016 at 4:55:32 PM UTC+2, Michael Harmon wrote:
>>>
>>> Hey,
>>>
>>> I had a similar problem: PDES in separate domains that are coupled 
>>> through an interface as a boundary condition.  You can go about it using 
>>> one triangulation; I attempted to do this at first, but ended up using 
>>> multiple meshes. The fact you have matching meshes on the boundary is 
>>> good.  What you want to do is create two meshes and two dof handlers.  
>>> Initially you need to create a std::map to create a bijection between the 
>>> faces on the different meshes that are on the interface/ connecting 
>>> boundary.  When you are assembling the coupling terms on the boundary 
>>> condition you can get the corresponding face in the other mesh and 
>>> initialize the fe_values on that face and get its values on the face to 
>>> assemble the boundary conditions.
>>>
>>> Check out:
>>>
>>> https://groups.google.com/forum/#!searchin/dealii/multiple$20triangulations%7Csort:relevance/dealii/R64BUBhyFf0/LbbxH9v8GgAJ
>>>
>>> If it helps I can also send you my code to see how to do this using 
>>> deal.ii
>>>
>>> Best,
>>>
>>> Mike
>>>
>>> On Thursday, July 28, 2016 at 2:17:12 PM UTC-4, krei wrote:


 The problem I am currently having is directly related to my previous 
 post [here](
 https://groups.google.com/forum/#!searchin/dealii/krei/dealii/eq_zP0jrSJU/SyQXA7A-DAAJ
 ).

 The physics are exactly the same as described in that thread: I have a 
 two domain system: vacuum and metal, both domains have their own meshes. 
 [Here is a picture](http://i.imgur.com/CejXi1y.png). The meshes are 
 exactly matching on the boundary. I want to solve the Laplace equation for 
 electric fields in the vacuum part (does not depend on anything in the 
 metal part) and then use the electric field as a boundary condition to the 
 metal part.

 I am currently using VectorTools::point_gradient to evaluate the 
 electric field from the Laplace problem in the quadrature points of the 
 boundary cell faces of the metal mesh. As a result, it takes over an hour 
 to assemble the system (solving takes less than a second). 

 Now, considering that the mesh is exactly matching at the boundary (all 
 the quadrature points etc), how could I efficiently evaluate the electric 
 field at the boundary?

 And I apologize if I'm mistaken, but there doesn't seem to be any 
 tutorials on these kinds of problems where you have multiple domains with 
 multiple meshes. Or is it usually done by using a single mesh and somehow 
 defining different domains in that mesh? (haven't delved deeply into 
 Step-46, but there they do something like this, right?)

>>> -- 
>> 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 a topic in the 
>> Google Groups "deal.II User Group" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/dealii/Uvi3-xhfHBk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> dealii+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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 

[deal.II] about deal.II with CUDA C programming acceleration

[Chih-Che Chueh]

Dear deal.II developers and users,

Recently, I spent some spare time assimilating CUDA C programming in the
last few months, and I already know very well how to use CUDA stream events
to let CPU and kernel (GPU) execution work asynchronously with efficiently
overlapping data transfer between CPU and GPU, how to use shared memory to
ensure global memory coalescing efficiently, how to map threads to matrix
elements either using CARTESIAN x, y, z or a row/column mapping in GPU, as
well as how to use shared memory to enhance data reuse. Most importantly,
for actual practice, we have a GPU accelerator (i.e. NVIDIA Tesla K40) that
was bought last year. I plan to use the CUDA C programming to deal with big
data or image identification with artificial intelligence (deep learning)
for atmospheric data.

Anyway, I am writing to ask if I could get involved with a deal.II project
of people who are working on asynchronous adaptive mesh refinement for
acceleration or other performance improvement in deal.II with CUDA C
programming.

Thanks!

Sincerely,

Chih-Che

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Using the solution from one problem as a boundary condition in another problem with matching mesh on the boundary

[vladislav . dealii]

Hello, Mike,

I have a similar problem like you. I have two PDEs in separate domains 
coupled through an interface. I have also tried to solve this using 
step-46.However, my code haven't produced the correct solution in my test 
case. Thus, I am very interested to try new approaches, especially how you 
have solved the problem using two different meshes (which of course fit on 
the interface). Could you send me a code snippet showing how you deal with 
the interface term and the vertices on the different meshes? It would be 
very helpful. Your idea using std::map makes sense to me, however I still 
can not really imagine how everything works together in the code.

Best,  
Vladislav

On Tuesday, August 23, 2016 at 4:55:32 PM UTC+2, Michael Harmon wrote:
>
> Hey,
>
> I had a similar problem: PDES in separate domains that are coupled through 
> an interface as a boundary condition.  You can go about it using one 
> triangulation; I attempted to do this at first, but ended up using multiple 
> meshes. The fact you have matching meshes on the boundary is good.  What 
> you want to do is create two meshes and two dof handlers.  Initially you 
> need to create a std::map to create a bijection between the faces on the 
> different meshes that are on the interface/ connecting boundary.  When you 
> are assembling the coupling terms on the boundary condition you can get the 
> corresponding face in the other mesh and initialize the fe_values on that 
> face and get its values on the face to assemble the boundary conditions.
>
> Check out:
>
> https://groups.google.com/forum/#!searchin/dealii/multiple$20triangulations%7Csort:relevance/dealii/R64BUBhyFf0/LbbxH9v8GgAJ
>
> If it helps I can also send you my code to see how to do this using deal.ii
>
> Best,
>
> Mike
>
> On Thursday, July 28, 2016 at 2:17:12 PM UTC-4, krei wrote:
>>
>>
>> The problem I am currently having is directly related to my previous post 
>> [here](
>> https://groups.google.com/forum/#!searchin/dealii/krei/dealii/eq_zP0jrSJU/SyQXA7A-DAAJ
>> ).
>>
>> The physics are exactly the same as described in that thread: I have a 
>> two domain system: vacuum and metal, both domains have their own meshes. 
>> [Here is a picture](http://i.imgur.com/CejXi1y.png). The meshes are 
>> exactly matching on the boundary. I want to solve the Laplace equation for 
>> electric fields in the vacuum part (does not depend on anything in the 
>> metal part) and then use the electric field as a boundary condition to the 
>> metal part.
>>
>> I am currently using VectorTools::point_gradient to evaluate the 
>> electric field from the Laplace problem in the quadrature points of the 
>> boundary cell faces of the metal mesh. As a result, it takes over an hour 
>> to assemble the system (solving takes less than a second). 
>>
>> Now, considering that the mesh is exactly matching at the boundary (all 
>> the quadrature points etc), how could I efficiently evaluate the electric 
>> field at the boundary?
>>
>> And I apologize if I'm mistaken, but there doesn't seem to be any 
>> tutorials on these kinds of problems where you have multiple domains with 
>> multiple meshes. Or is it usually done by using a single mesh and somehow 
>> defining different domains in that mesh? (haven't delved deeply into 
>> Step-46, but there they do something like this, right?)
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Installation didn't give any errors but when I tried make test, it failed all tests

[Denis Davydov]

Hi Japan,

I am happy to hear that it worked and you resolved your problem!

Sincerely,
Denis.

> On 14 Aug 2017, at 04:13, Japan Patel  wrote:
> 
> Hey everyone,
> 
> Thanks Dr. Bangerth and thanks Denis!!
> 
> I was able to run step-1. I installed using spack. It took a while to 
> download all the packages and install them but it was worth it as I was able 
> to run an example problem which I wasn't able to before and all the packages 
> are already linked which would have been a huge hassle had I installed them 
> separately and then tried to link with dealii. Thank you so much for shipping 
> dealii in this format. I really appreciate it! 
> 
> I think I can follow Dr. Bangerth's online lectures now and learn how to use 
> dealii. 
> 
> Sincerely,
> Japan
> 
> On Sun, Aug 13, 2017 at 11:29 AM,  > wrote:
> Thanks. I was able to find the other thread regarding my problem and was able 
> to use the correct cmake flags to get dealii to install correctly. Thank you 
> for your help!
> 
> On Saturday, August 12, 2017 at 5:50:13 PM UTC-6, Wolfgang Bangerth wrote:
> On 08/12/2017 05:21 PM, drgeoff...@gmail.com <> wrote: 
> > I'm wondering if I could tag onto this message. I'm having a similar 
> > problem. 
> > Installed with no problems. However, when I run the tests, they all fail 
> > with 
> > the error: 
> > 
> > symbol lookup error: /usr/lib/libumfpack.so.3.1.0: undefined symbol: 
> > amd_realloc 
> 
> That seems like a separate issue unless you also get the error messages about 
> the CXXABI or GLIBCXX version mismatch. 
> 
> I think there was a question about your error on the mailing list a while 
> ago. 
> Can you try to search for it? 
> 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/N3WvNvLV3lg/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.