Re: [deal.II] SynchronousIterators compilation errors

Dear Claire, In the next version of deal.II we will be requiring the compilers be C++11 compatible. We therefore removed this namespace wrapper (less for us to maintain) and, as you suggest, require that users use namespace std instead. So yes, you probably need only substitute all instances

Re: [deal.II] Output nodal scalar

Dear Jie, Your query relates to this FAQ post . You’ll likely find that DataOut is holding a pointer to the DataPostprocessorTensor, and the

Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?

? I presume from what you said earlier its in /usr/[include/lib]? but still it prefers the one in /usr/include/) On Thursday, August 31, 2017 at 3:44:08 PM UTC+2, Jean-Paul Pelteret wrote: > > @timo > > Can you provide us with your >> detailed.log from candi/tmp/build/de

Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?

@timo Can you provide us with your > detailed.log from candi/tmp/build/deal.*/ ? > Daniel already did so in the 4th post in this thread: #DEAL_II_WITH_PETSC set up with external dependencies > #PETSC_VERSION = 3.7.6.0 > #PETSC_DIR =

Re: [deal.II] Re: PETSC_HAVE_MUMPS not set correctly ?

Dear Daniel, Yes, I see that making this change will actually definitely make it fail. I’ve set to correct this with PR #4994 - you could try to patch your version of deal.II with this fix, but I’m not sure that it’d make any difference to you. For

[deal.II] Re: PETSC_HAVE_MUMPS not set correctly ?

ake#L142>. Can you change this line accordingly and see if that works? If so, would you like to open a pull request with the fix? On Wednesday, August 30, 2017 at 12:07:07 PM UTC+2, Jean-Paul Pelteret wrote: > > Dear Daniel, > > Looking at the CMake configuration module f

[deal.II] Re: PETSC_HAVE_MUMPS not set correctly ?

Dear Daniel, Looking at the CMake configuration module for PETSc , it would seem that this is a flag that is picked up from the PETSc installation itself. Have you configured

[deal.II] Re: Best way to transfer old solutions in time stepping over mesh refinement?

Dear Maxi, I'm going to put my foot down and say that, particularly as of late, you're not giving your problems sufficient attention before posting them to the forum. We have a set of guidelines https://groups.google.com/forum/#!topic/dealii/GRZMUTLIm2I (which, to the best of my recollection,

[deal.II] Re: Assembly of matrices for the heat equation when using Sacado generates -nan-values

Thanks for giving feedback as to what the source of the issue was. I'm glad that you resolved your problem! On Tuesday, August 29, 2017 at 10:09:57 AM UTC+2, Maxi Miller wrote: > > Found my problem, it was the remeshing. Whenever I was remeshing, I > basically killed the old solution, which

Re: [deal.II] Re: if else leading to the same path in step 44

as > > On 28 August 2017 at 17:40, Jean-Paul Pelteret <> wrote: > >> Dear Lucas, >> >> You're welcome. Thanks for the discussion and your feedback! I've made a >> note to myself <https://github.com/dealii/dealii/issues/4979> to improve >> the doc

Re: [deal.II] Re: if else leading to the same path in step 44

hat the lack of the else could lead to errors > that quite hard to track down. However, I think adding your comment to that > part of the tutorial could save someone having the same issues I faced. > > Thanks for your time, > Lucas > > On 28 August 2017 at 17:26, Jean-Paul Peltere

Re: [deal.II] Re: if else leading to the same path in step 44

s, Jean-Paul On Monday, August 28, 2017 at 5:26:08 PM UTC+2, Jean-Paul Pelteret wrote: > > Hi Lucas, > > I see, now I understand to what you were referring. > > Yes, the specific example that you've shown here is an intentional > redundancy. Previous experiences has shown that

Re: [deal.II] Re: if else leading to the same path in step 44

gt; > Also, in your answer you mentioned that in the second call (iteration == > 1), only homogeneous constrains will be built. I also cannot see this from > the code. Perhaps this part is interacting with some other part of the code > in a way I cannot see? > > Thanks for the help

Re: [deal.II] Using deal.II logo in publication

Maybe, but its not our current logo but rather a new one? ;-) On Monday, August 28, 2017 at 5:00:12 PM UTC+2, Timo Heister wrote: > > My counter: >

[deal.II] Re: if else leading to the same path in step 44

Hi Lucas, So it sounds as if you've already worked out what's happening here. We consider 3 cases, namely what to do for newton iteration equal to 0, equal to 1, and greater than 1. For iteration == 0 and iteration == 1, the early return on line 2468

[deal.II] Re: Anisotropic fe space

Hi Praveen, I'm a little bit naïve when it comes to these things, but can you not achieve this by using an FESystem with each component given by a different FE and ensuring that all components are fully coupled? Regards, Jean-Paul On Monday, August 28, 2017 at 12:32:33 PM UTC+2, Praveen C

Re: [deal.II] Using deal.II logo in publication

Is it possible to do another one with the “deal.II” name on the RHS, like was in the original image? I think that would complete the set :-) > On 27 Aug 2017, at 12:26, Jean-Paul Pelteret <jppelte...@gmail.com> wrote: > > I think that looks great! > >> On 27 Aug 2017,

Re: [deal.II] Using deal.II logo in publication

I think that looks great! > On 27 Aug 2017, at 11:54, Denis Davydov wrote: > > ok, so here's a symmetric by construction logo (from 1/8th of the traced > image. > > > -- > The deal.II project is located at http://www.dealii.org/ > > For mailing

[deal.II] Re: Output nodal scalar

Yes, thats correct :-) The book link that you mention outlines the problem exactly as I understand it, and I interpret it in the same way as you've mentioned. On Friday, August 25, 2017 at 4:30:19 PM UTC+2, Jie Cheng wrote: > > Dear Jean-Paul > > Now I understand why the heuristic method is

[deal.II] Re: Possibility to output stuffs on the integration points?

Triangulation or DoFhandler object at the time > of output? Thanks in advance. > > Regards, > Chuyi > > 在 2017年7月14日星期五 UTC+2下午4:43:47，Jean-Paul Pelteret写道： >> >> Dear Chuyi, >> >> No, as far as I am aware we have no specific function to help do this for

Re: [deal.II] Using Sacado with example 15

> > I suspect that this can be written even more concisely with the current > development version of deal.II. For example, I'm pretty sure you can write > >std::vectorSacado::Fad::DFad> > grad_u (n_q_points); > >fe_values.get_function_gradients (solution, grad_u);

[deal.II] Re: Output nodal scalar

Dear Jie, > it seems that the L2-projection method also evaluates the stress tensor at > the quadrature points and then finds the cell-averaged stress. The only > difference compared with the heuristic method is that it solves AX = Y > where A is mass matrix, Y is integration of

[deal.II] Re: Output nodal scalar

7 at 6:35:18 PM UTC+2, Jean-Paul Pelteret wrote: > > I can't think of any off of the top of my head, but I think that > MatrixCreator::create_mass_matrix() > <https://www.dealii.org/8.5.0/doxygen/deal.II/namespaceMatrixCreator.html#aa95a194001f23f96327fb7a630c6b036>

[deal.II] Re: Output nodal scalar

xamples programming-wise? Like a deal.II manual/tutorial... > > Jie > > On Thursday, August 24, 2017 at 11:27:40 AM UTC-4, Jean-Paul Pelteret > wrote: >> >> Hi Jie, >> >> Sure, we used it in this paper >> >>> @Article{vogel2014a

[deal.II] Re: Output nodal scalar

r your second suggestion on L2-smoothing, I'd like > to give it a try. Can you please point me to some detailed references? > Examples or documentations would be great! > > Jie > > On Thursday, August 24, 2017 at 1:53:36 AM UTC-4, Jean-Paul Pelteret wrote: >> >> Dear

[deal.II] Re: Multiply SparseMatrix and a Vector

Dear Nitish, Well, in the documentation to vmult it states that when > the current object represents a parallel distributed matrix (of type >

[deal.II] Re: Using deal.II logo in publication

Dear Martin, Thank you for asking about using the deal.II logo in your publication! I'm not sure what the restrictions on its use are, so I'm going to defer this question to the other developers who have more specific knowledge in this regard. I'm sure that you'll have an answer by tomorrow.

[deal.II] Re: Output nodal scalar

Dear Jie, I'm glad to hear that you managed to find a solution to your problem and for posting what it was. Two quick points: 1. There's actually another add_data_vector() member

[deal.II] Re: trilino installation problem

Hi Chih-Che, I suppose the obvious first question is what the output of the following two commands are which cmake cmake --version and whether or not those match that expected after you've load the CMake module. Regards, Jean-Paul On Wednesday, August 23, 2017 at 9:20:41 AM UTC+2, Chih-Che

[deal.II] Re: Calling fortran subroutine from my deal.II code

Hi Praveen, I know its been a long time since you posted this question, but it caught my eye again recently. Matthias has posted an explanation on GitHub as to how to work around if you're using an older version of deal.II,

[deal.II] Re: Acess to Each component of RHS

Dear Kyusik, That is, "component == 0" of RHS would correspond to x component of RHS and > "component ==1 " would correspond to y component of RHS. > The "component" refers to each component of your FESystem. For a scalar problem, there is only 1 component, for a system with a single

Re: [deal.II] Re: Reading Abaqus boundary conditions

Dear Jie, Great, I'm glad that you've managed to read in a grid with boundary indicators! Does this mean I should define a surface in Abaqus to indicate where I want > to apply displacement bc? > I would presume so. This is how it must be done when using Cubit, and I would suspect that the

[deal.II] Re: Acess to Each component of RHS

Dear Kyusik, So if I understand you question correctly, you're not sure how to compute the "grad_p" part of the RHS during assembly? This you would do using the get_function_gradients()

Re: [deal.II] 2D waveguide using Nedelec elements

Hi Rolf, Step-55 has PETSc compatibility and constructs a block system. You can look there for information as to how to initialise the block system. I hope that this helps. Regards, Jean-Paul On Friday, August 18, 2017 at 3:38:19 PM

[deal.II] Re: Iterate over cell centers

Dear Nitish, If you are wanting to iterate over cell centres (or, rather, iterate over cells and query them for their centre), then you would do very similar to what you've posted: for (typename Triangulation::active_cell_iterator cell=triangulation.begin_active();

Re: [deal.II] Re: Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

rto Salvadori* Dipartimento di Ingegneria Civile, Architettura, > Territorio, Ambiente e di Matematica (DICATAM) > Universita` di Brescia, via Branze 43, 25123 Brescia > Italy > tel 030 3711239 > fax 030 3711312 > > e-mail: > al

[deal.II] Re: Post-processing: how can the method compute_derived_quantities_vector be informed about cell->user_pointer() ?

Dear Alberto, It looks like one can already do this, although its somewhat obscurely documented. Here's a link to the documentation of the CommonInputs class , wherein you can find a documented

Re: [deal.II] constraint around hole / equivalent node

Dear Tuanny, There is no way to do this when reading in from a mesh file. You can, however, add this constraint manually. See this post https://groups.google.com/forum/#!searchin/dealii/vertex_dof_index%7Csort:relevance/dealii/8fUwabkznaU/VlTERBo-GQAJ and other post that reference

Re: [deal.II] Re: Reading Abaqus boundary conditions

Hi Jie, > That should be the way to do it. I don't know whether our Abaqus reader > actually reads boundary values, though. You may have to take a look at the > source code. > Yes it does, but the boundary ID's must be prefixed. It looks like you have to name the surfaces > SS or >

[deal.II] Re: Reading Abaqus boundary conditions

Hi Jie, Unfortunately this is not possible to do in our current implementation. The format of an Abaqus mesh file is quite general, and suggested by the documentation our parser has only the

[deal.II] Re: errors when installing dealii-8.5.1 after successful cmake configuation

Hi, Did you delete your build directory after renaming the parent directory? If not, then you might want to do so and try to configure and build deal.II again. Sometimes CMake caches some data that remains stale even after a project is reconfigured. I hope that this helps, Jean-Paul > --

Re: [deal.II] Component Mask for setting initial conditions

Yeah, thats pretty much it. Judging from the output, each of your FEExtractors is vector valued, so fe_values[N_density] returns a vector-valued view and fe_values[N_density].value(i, q_point) is the i'th vector valued *shape function* (not DoF value) associated for the N_density vector field

Re: [deal.II] Component Mask for setting initial conditions

Dear Maxi, Aligned with Wolfgang's thoughts (and considering your recent flurry of posts), it seems like you need to slow down and more carefully consider what you are doing in your work. We all have to work through bugs and conceptual issues - this is part of learning both the deal.II, or any

Re: [deal.II] Function for VectorTools::interpolate_boundary_values with different boundary values in multi-variable system

Dear Maxi, It would have been helpful if you'd posted the full error. However, I'm guessing that this is the problem: The function that you're trying to call is void

[deal.II] Re: How to clear data of triangulation completely

Dear Felix, Like Bruno said, if you call clear() on the triangulation at the end of this cycle then it should work. Here you can see that regardless of what other objects are

[deal.II] Re: Defining "complex" geometry for hand drawn mesh

I agree completely with Bruno. Generating quadrilateral meshes for arbitrary geometries is not a trivial task (for every complex mesh that you envision, someone could likely dream up of a more challenging scenario). When you add the constraint that the mesh has to be of good quality, and have

[deal.II] Re: Extracting results along line or surface

Hi Ehsan, I don't use Visit, but Paraview has the functionality to plot a solution over a curve. Have you looked at the Visit tutorials for information as to how you might to this in Visit? Looking at this one

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

es. >> Thanks again for reporting the problem! >> >> Best, >> Jean-Paul >> >> On Tuesday, July 25, 2017 at 10:13:51 AM UTC+2, Giovanni Di Ilio wrote: >>> >>> Dear Jean-Paul, >>> >>> (I tried also version 8.4.1 and same problem).

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Anna, > I am new to deal.ii > Welcome to the deal.II community! > when using LinearOperators I am not actually constructing the matrix, but > only know how such matrix would act on a vector. Am I correct? > Yes, thats exactly correct. > Could you please let me know whether I

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

> Thank you for the prompt reply. The inverse of the matrix addition will be > used to construct a preconditioner for the solution of the original system > with FGMRES. > > On Wednesday, July 26, 2017 at 3:15:51 PM UTC+9, Jean-Paul Pelteret wrote: >> >> Dear Anna, >&

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Anna, So it appears that you're hitting this assertion , which is not checking that the sparsity pattern looks the same but rather that both blocks reference the same sparsity pattern object

[deal.II] Re: website petsc tutorial

tsc 3.6.0. As I may recall, 8.4.1 is > compatible with 3.6.4, right? > > All best, > YC Chen > > On Tuesday, July 25, 2017 at 3:50:41 PM UTC+1, Jean-Paul Pelteret wrote: >> >> Dear Yi-Chung, >> >> Thanks for the information, but this is done by design (so th

[deal.II] Re: website petsc tutorial

Dear Yi-Chung, Thanks for the information, but this is done by design (so there is no problem). At the time of the release of deal.II 8.5.0, the content linked to on http://www.dealii.org/8.5.0/external-libs/petsc.html

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

Dear Giovanni, Thank you very much for the clear and simple test case! I've played around with it and I don't see any fault in the way that you're trying to use the mapping functionality, so I think that its quite clear that there's something wrong with Mapping::transform_real_to_unit_cell.

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

helpful. > Please let me know if I can provide some more useful information. > Thank you very much again, > > Best, > Giovanni > > > > On Thursday, July 20, 2017 at 9:08:34 PM UTC+2, Jean-Paul Pelteret wrote: >> >> Dear Giovanni, >> >> Its good to hear t

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

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

ve 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 >> <http://dealii.org/developer/dox

[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

[deal.II] Re: Modification of right hand side of example 52 for multiple equations leads to linker error

Dear Maxi, The problem is that you're instantiating the time integration class Table<1, Vector> with a data type that is not a deal.II vector (Vector, BlockVector, TrilinosWrappers::Vector etc.). The instantiation takes place here

[deal.II] Re: openmp flag in CMake?

Dear Kartik, There's both a section in the main and user-project documentation on CMake about how to configure CMake with extra compile and linker

[deal.II] Re: Possibility to output stuffs on the integration points?

Dear Chuyi, No, as far as I am aware we have no specific function to help do this for you. However, there is an example in the code-gallery that shows how to

Re: [deal.II] Re: hp HDG in deal.II

Dear Simon, 1. Track deal.II's remote master branch git remote add dealii g...@github.com:dealii/dealii.git 2. Fetch the up-to-date master from the deal.II remote git fetch dealii 3. Merge or rebase as necessary: git merge dealii/master or git rebase master In all likelihood "rebasing" is the

[deal.II] Re: Adding external library to libdeal_II

Hi Victor, Another think that I noted is that the file mysolver.cc that I added under > source/lac is not being compiled and linked to libdeal_II.so (I could not > find it in the link.txt file that I attached). Do I need to do something > else in order to cmake recognize that this file need to

[deal.II] Re: Adding external library to libdeal_II

in my library). > > Thank you! > > On Tuesday, July 4, 2017 at 3:47:38 PM UTC+2, Jean-Paul Pelteret wrote: >> >> Dear Victor, >> >> Can you clarify something: Have you modified a copy of deal.II such that >> your library is now an explicit dependency (i.e. dea

[deal.II] Re: Adding external library to libdeal_II

Dear Victor, Can you clarify something: Have you modified a copy of deal.II such that your library is now an explicit dependency (i.e. deal.II now has some function calls to your library), or is your library only being referenced through some functions called inside another code (e.g. "step-3"

[deal.II] Re: The violated condition was: (update_flags & update_normal_vectors) == false

Dear Franck, It looks like you're passing the flag "update_normal_vectors" to an FEValues object, which is not sensible as it is used only for volume calculations (as opposed to surface calculations). I think that this is the propogation of the flags that leads to the issue:

Re: [deal.II] Re: hp HDG in deal.II

I've updated the Wiki entry to point to the video lecture as well. On Wednesday, June 28, 2017 at 12:08:12 PM UTC+2, Wolfgang Bangerth wrote: > > On 06/26/2017 07:12 AM, sml.imf...@gmail.com wrote: > > > > Thanks for your answer, your approach actually worked quite well. (How > would I > > go

[deal.II] Re: slepc installation error - How does one find the CHECKSUM for slepc to put in /candi/deal.II-toolchain/packages/slepc.package ?

Hi Kartik, It looks like candi uses md5 to verify downloads. What you could do is manually download the file off of their website and run "md5 slepc-3.7.4.tar.gz" to compute the checksum yourself. I hope that this helps! Regards,

Re: [deal.II] Installation error

Hi Lev, The information that you were looking for is in the CMake related documentation . You need to pass the -DDEAL_II_FORCE_BUNDLED_THREADS=ON option at configuration time. I hope that this helps. Regards, J-P On Tuesday,

Re: [deal.II] Re: component mask and Dirichlet bc application

Dear Alberto, Thanks for your feedback. We'll take a look at the documentation and try to see how/where it can be enhanced. Best, Jean-Paul On Thursday, June 1, 2017 at 12:51:42 PM UTC+2, Alberto Salvadori wrote: > > Thank you Jean Paul, > very clear. Perhaps your notes could be added on the

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, Great! We're looking forward to your contribution :-) Best, J-P On Tuesday, May 30, 2017 at 8:14:55 AM UTC+2, Julian A wrote: > > I'm happy to do so. I will start next week when I'm in the office again. > > Thanks for the suggestions. > > Regards > -- The deal.II project is

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, Here's the reference to the issue <https://github.com/dealii/dealii/issues/4443> I've just opened on GitHub. Best, J-P On Tuesday, May 30, 2017 at 7:54:18 AM UTC+2, Jean-Paul Pelteret wrote: > > Hi Julian, > > Well, it seems then that my lack of optimism in my s

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

objects > correctly I get the expected log from Aztec. > > On Tue 30. May 2017 at 07:10, Jean-Paul Pelteret <> wrote: > >> Hi Julian, >> >> I had a quick look in the source code to verify that this flag is being >> passed >> to the solver >>

[deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, I had a quick look in the source code to verify that this flag is being passed to the solver (it is). I've not used this option before so I'm afraid I don't have many ideas. The only thing that comes

[deal.II] Re: "operator+=" error in the assemble_system()

Dear Kyusik, Firstly (and just so that we're all clear on what you're trying to implement), was I correct that your comment that I linked contained the description of the integral that you are trying to compute? > As far as I know fe_values2.shape_value(i,q_index) is vector-valued shape >

[deal.II] Re: Getting error during cmake configuration step and later during make run

Hi Vikram, I'm sorry that you've encountered trouble using the MacOS package. I see that there might have been some issues with regards to the bundling of the package, but I'm not actually sure if they're related. I have no experience with this

[deal.II] Re: Adding periodicity to a thin sample with one element in thickness direction

Hi Hamed, You're welcome. I'm glad that we helped you resolve the issue! Best, Jean-Paul On Wednesday, May 17, 2017 at 4:07:08 PM UTC+2, Hamed Babaei wrote: > > Hello all, > > You are right. I was running in debug mode, slowing down the code. > Thank you very much for your incredible help. I

[deal.II] Re: assembling question

You're welcome! On Wednesday, May 17, 2017 at 1:08:24 PM UTC+2, Ashkan Dorostkar wrote: > > Thank you, > This helped a lot. I didn't remember that rule at the moment. > > Ali > > On Wednesday, May 17, 2017 at 12:38:48 PM UTC+2, Jean-Paul Pelteret wrote: >> >

[deal.II] Re: assembling question

Dear Ali, If you apply the product rule to this term, does it then look a little more managable? Regards, Jean-Paul On Wednesday, May 17, 2017 at 12:20:18 PM UTC+2, Ashkan Dorostkar wrote: > > Dear all, > I want to solve a system of equation for

Re: [deal.II] Error in the second derivative of solution...?

Thats great! I'm glad that you've managed to work it out :-) Best, Jean-Paul On Wednesday, May 17, 2017 at 10:06:18 AM UTC+2, hanks0...@gmail.com wrote: > > Thank you very much!! > > It seems that I can solve my problem. > > Thank you! > > Kyusik. > -- The deal.II project is located at

[deal.II] Re: cmake-gui mpi

Dear Peng, This part of the installation documentation suggests that you can explicitly indicate which MPI compilers to use with the following flags passed to CMake: cmake -DDEAL_II_WITH_MPI:BOOL=ON -DCMAKE_C_COMPILER="" >

[deal.II] Re: Adding periodicity to a thin sample with one element in thickness direction

Ah, Daniel beat me to it. I took too much time putting together another demo code :-) Aligned with Daniel suggested, I'd bet you're running in debug mode. Here's the output of the attached code running in release mode for 1000x1000x1 repetitions: $ make release > [100%] Switch

[deal.II] Re: Adding periodicity to a thin sample with one element in thickness direction

; } > > int main (int argc, char *argv[]) > { > Utilities::MPI::MPI_InitFinalize mpi_initialization(argc, argv, 1); > Solid<3> solid_3d; > solid_3d.make_grid(); > } >

Re: [deal.II] Error in the second derivative of solution...?

Hi Kyusik, What makes me confused here is that, according to your explanation, two > different DoFHandler could be used simultaneously. > Yes, that it correct. You can convert between cell iterators. So I do the following: typename Triangulation::active_cell_iterator cell

Re: [deal.II] Error in the second derivative of solution...?

Dear Kyusik, > I'm sorry to tell you that actually I don't know how to project > grad_solution into the vector-valued FE space > > Do you happen to know some example tutorial code that includes it? > Off the top of my head, no I don't know of an example tutorial that demonstrates it.

[deal.II] Re: Step-42

Dear Benhour, I think that you must have misinterpreted what Daniel suggested. If I run ./step-42 p1_adaptive.prm > then this tutorial works fine for me. If I run "make run" then the (unusual) error message appears for me as well. Regards, Jean-Paul On Monday, May 15, 2017 at 7:30:25 PM

[deal.II] Re: Step-42

Dear Benhour, I would suggest removing the CMakeCache.txt file and CMakeFiles directory (both located in the tutorial/build directory). Then rerun CMake before trying to build the tutorial. It might be that there are some stale configuration settings that need to be updated. Regards,

Re: [deal.II] Error in the second derivative of solution...?

Dear Kyusik, So my new question is , in deal.II, could I get local divergence of certain > function to get surface integral? > >> Yes it is. You can extract the divergence of a function using, for example, the FEValuesView function get_function_divergences

[deal.II] Re: Adding periodicity to a thin sample with one element in thickness direction

Dear Hamed, Although I don't really understand your specific question, I am guessing that you were wondering if its possible to use the "repetitions" parameter to bias the initial mesh gradation before adding periodicity (since the periodic face pairs must be chosen on the on the coarsest

[deal.II] Re: Error in "make" invoking Trilinos

Hi Oliver, I think that this line indicates the problem: .../dealII/8.5.0/examples/test02/tril/test02_tril.cc:129:3: error: > ‘TrilionsWrappers’ does not name a type > TrilionsWrappers::MPI::Vector system_rhs; You've misspelt the namespace name "TrilinosWrappers" :-) Best, Jean-Paul On

[deal.II] Re: Trouble with integrating Trilinos with Deal II

Dear Tim, Thanks for letting us know that you finally got it installed. Thats good to know in case anyone else experiences similar problems in the future. I've had a look at our readme entry on Trilinos , and it looks like to don't

[deal.II] Re: How to generate the mesh to characterize discontinuities in a rectangular waveguide

Dear Jianan, deal.II does have some tools that can help you to incrementally build up complex meshes. These helper functions include GridGenerator::create_triangulation_with_removed_cells

Re: [deal.II] Setting smooth coefficients in space

see > https://github.com/dealii/dealii/pull/4339 > > Best regards, > Kostya > > вторник, 2 мая 2017 г., 20:05:28 UTC+3 пользователь Jean-Paul Pelteret > написал: >> >> Hi Konstantin, >> >> Thank you for your answers! >>> >> >> You're w

[deal.II] Re: Undefined reference error while running make test

detailed.log). > > Regards, > Amir > > On Tuesday, May 2, 2017 at 1:23:13 AM UTC-4, Jean-Paul Pelteret wrote: >> >> Dear Amir, >> >> At the top of the quick test log, this line suggests what the issue is: >> >>> ../../lib/libdeal_II.g.so.8.2.

Re: [deal.II] Setting smooth coefficients in space

Hi Konstantin, Thank you for your answers! > You're welcome! > As I see the actual problem is to define a step function for material > parameters. In FEM simulations mesh is often aligned to the problem`s inner > interfaces (like in a "Better mesh" extension of step-6). Is it possible to

[deal.II] Re: Undefined reference error while running make test

Dear Amir, At the top of the quick test log, this line suggests what the issue is: > ../../lib/libdeal_II.g.so.8.2.1: undefined reference to `SuiteSparse_realloc' > > So there's either a problem with your SuiteSparse installation (which contains UMFPACK) or its configured incorrectly with

Re: [deal.II] Re: muparser error while compiling code against deal.ii from git master

Hi Praveen, Great, thanks for letting us know! Best regards, J-P On Thursday, April 27, 2017 at 2:38:13 PM UTC+2, Praveen C wrote: > > This seems to be fixed on git master. I am able to compile my code now. > > Best > praveen > > On Tue, Apr 25, 2017 at 10:32 AM, Jean-P

[deal.II] Re: How to provide the VectorMemory<BlockVector > for the class SchurMatrix?

Dear Jesse, You can probably just provide an instance of the GrowingVectorMemory class templated on BlockVector< double >. So this would look something like: GrowingVectorMemory< BlockVector > memory; const

[deal.II] Re: muparser error while compiling code against deal.ii from git master

Hi Praveen, I see that there's some more work going on in this pull request , so any input that you have with this patch applied would be appreciated. Best, J-P On Tuesday, April 25, 2017 at 5:56:57 AM UTC+2, Praveen C wrote: > > When compiling my

Re: [deal.II] Re: imposing boundary conditions for a three-fields formulation

il: > alberto.salvad...@unibs.it > web-pages: > http://m4lab.unibs.it/faculty.html > http://dicata.ing.unibs.it/salvadori > > On Tue, Apr 18, 2017 at 11:10 AM, Jean-Paul Pelteret <> wrote: > >> Dear Alberto, >> >> The correctness of my answer depends on

<    1   2   3   4   5   6   >