Re: [deal.II] Post Processing of an Electrostatic Field

Hi Professor Bangerth, Thanks for the quick reply! According to your guidance, I found more useful posts about this topic and finally I referenced the heat flux example and got it work. By the way, I really appreciate you guys' work on the dealii package. It's a great FEA tool! Best, Baoyun G

Re: [deal.II] Post Processing of an Electrostatic Field

On 07/20/2017 04:23 PM, Baoyun Ge wrote: I am using dealii to solve the electrostatic field governed by Laplace's equation. Right now I have the solution vector, which contains the electrical potential information throughout all the degrees of freedom. I am stuck at the post processing phase,

[deal.II] Post Processing of an Electrostatic Field

Dear All, I am using dealii to solve the electrostatic field governed by Laplace's equation. Right now I have the solution vector, which contains the electrical potential information throughout all the degrees of freedom. I am stuck at the post processing phase, where I want to evaluate the ch

Re: [deal.II] Re: The violated condition was: (dst_local_size) == (static_cast(matrix->RangeMap().NumMyPoints()))

Franck, Thank you for your reply. I have tried what you suggested still the problem persists. It is exactly the same linear solver as in step43 which I plan to write the parallel. I have not write every thing but just the darcy part in it simple way that. I attach the file in case you want

Re: [deal.II] Mapping points of mesh generated by gmsh

Dear Giovanni, Its good to hear that you managed to solve / work around this issue! Would it be possible for you to post the reduced (problematic) mesh so that we can see if there's anything that we can learn from it. I'm guessing that you expected lines with entries such as 6 0.1999108

Re: [deal.II] Mapping points of mesh generated by gmsh

Dear Wolfgang, thanks for your quick reply and for your suggestion. I simplified the case to only two cells, the one that was supposed to be "wrong" and one of its neighbours, that was supposed to be ok, for comparison. By watching at the coordinates of the vertices in the file .msh I found out

Re: [deal.II] Re: The violated condition was: (dst_local_size) == (static_cast(matrix->RangeMap().NumMyPoints()))

Hi W B Thank you for your reply. I have tried what you suggested still the problem persists. It is exactly the same linear solver as in step43 which I plan to write the parallel. I have not write every thing but just the darcy part in it simple way that. I attach the file in case you want to h

Re: [deal.II] Mapping points of mesh generated by gmsh

On 07/20/2017 05:53 AM, Giovanni Di Ilio wrote: I provide a small code that I am testing as well as the .msh and .geo files I am using. The code computes the mapped point of a generic real point which is placed in the center of a "sick" cell (id=354). I would expect that the coordinates of th

Re: [deal.II] Re: Usage of `extract_subvector_to`

On 07/20/2017 05:42 AM, Jean-Paul Pelteret wrote: (I would have expected something else) We're always happy to receive contributions that improve the documentation! :-) Indeed, seriously! The documentation for that function is in the file inclu

Re: [deal.II] Expanding example 52 to multiple equations

[...lots of code...] But I am not sure if that is even remotely correct. This is really too broad a question. If you try it, what concretely goes wrong? How does fe_values_N differ from fe_values_TE? But how should I initialize them else? Should I use FESystem instead? If yes, how should I in

Re: [deal.II] how to use post_processor for FE_System

Thanks!! By the way, can I ask another? Actually, the quantity that I'm going to calculate is \dot(gamma), More explicitly...I attach one figure

[deal.II] Mapping points of mesh generated by gmsh

Dear Deal.II community, I am facing a problem with the mapping of a point on the real cell to the unit cell when the mesh is read in from a .msh file. So what I have is a .geo file (which contains "physical lines" and "physical surfaces", as indicated in Step49). I generate the .msh file and I

[deal.II] Re: Usage of `extract_subvector_to`

> > (I would have expected something else) > We're always happy to receive contributions that improve the documentation! :-) On Thursday, July 20, 2017 at 1:33:37 PM UTC+2, Maxi Miller wrote: > > Slightly confusing (I would have expected something els

[deal.II] Re: Usage of `extract_subvector_to`

Slightly confusing (I would have expected something else), but that explains it. Thanks! Am Donnerstag, 20. Juli 2017 13:23:46 UTC+2 schrieb Jean-Paul Pelteret: > > Dear Maxi, > > The documentation for the alternate version of the function >

[deal.II] Re: Usage of `extract_subvector_to`

Dear Maxi, The documentation for the alternate version of the function gives a hint at whats going on here. The iterators that you're sending in are not the start and end point for the data to be c

[deal.II] Expanding example 52 to multiple equations

I still have some problems trying to understand when to use multiple DoFHandler-variables/FE_Q-variables, and when to use only one. I am trying to expand example 52 to multiple coupled equations. My initial approach is to expand the functions from (here assemble_system) FEValues<2> fe_values(fe,

[deal.II] Usage of `extract_subvector_to`

I wanted to test how to use the function extract_subvector_to in order to slice a part of a vector and put the result into another vector. Using a short test program Vector vec_1 = Vector(9); Vector vec_2 = Vector(vec_1.size()/3); for(size_t i = 0; i < vec_1.size(); ++i) vec_