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

Dear Alberto, The correctness of my answer depends on the numbering assigned to the degrees-of-freedom, which is something that you've not mentioned above. But from what I can discern the 9th row relates to the pressure test function, so K_{8,[0-7]} are the components from the coupling block

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

Hi Alex, > Yes I began this project by reviewing step-8 > > and > the Handling vector valued problems >

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

Ok great, I'm glad that you're getting somewhere. So lets try to get to the bottom of this indexing issue (as a side note, and in case anyone else is interested, in this issue we've started discussing how to document the index-related functions in

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

> > Hi Alex, >> > > Thanks for the clarification, Jean-Paul. > I'm sorry to say that you shouldn't be too quick in this instance to thank me... > I'm glad to hear that my syntax is correct. > > I am indeed using an extractor, e.g. here's a line from my code: > const Tensor<2, dim> gradv

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

Dear Alex, What you've stated is correct. The tensor component $S_{ij}$ is exactly component S[i][j] of a Tensor<2,dim> S if "S" represents $S_{ij} = \partial v_{i} \partial x_{j}$. As for an example, both steps 18

[dealii-developers] Version of step-44 from deal.II 7.2

Dear all, Does anyone have deal.II version 7.2 lying around? I'm looking for the first official version of the step-44 tutorial that came with this release. If someone has access to this then I'd appreciate you sending me the source and parameter file! Unfortunately I've only got v7.1 and

Re: [deal.II] Fe_values->shape_grad() wrt to reference mesh

Dear Rajat, > You don't have to know *advanced* concepts, but you should know at least > the > basics. I always think that the book by Stroustrup is a good starting > point, > but there are many others that are also good. > To briefly add to this, we list a few websites on our wiki page

Re: [deal.II] Re: Run into a cluster

Hi Joaquin, Its been a really long time since I compiled Lapack manually and linked it against deal.II (at that time, before we used CMake). I've attached for you a file with my personal notes on how I used to compile Lapack then (circa 2012). I think that you've pretty much covered all of the

Re: [deal.II] Re: linking to lapacke

4lab.unibs.it/faculty.html > http://dicata.ing.unibs.it/salvadori > > On Mon, Mar 27, 2017 at 10:48 AM, Jean-Paul Pelteret <> wrote: > >> Hi Alberto, >> >> So, if I understand correctly, you've made modifications to the >> CMakeLists.txt that governs your

[deal.II] Re: linking to lapacke

Hi Alberto, So, if I understand correctly, you've made modifications to the CMakeLists.txt that governs your modified example problem as opposed to linking deal.II itself directly to Lapack. I would say that the most simple (although time-consuming) way to get the correct linker line would be

[deal.II] Re: Run into a cluster

Dear Joaquin, This would appear to be an issue with the way that blas is compiled: See these search results for some more info. If this were installed by a system administrator then you should ask them to

Re: [dealii-developers] authors.html format

Ditto. On Thursday, March 23, 2017 at 8:49:56 PM UTC+1, Matthias Maier wrote: > > > On Thu, Mar 23, 2017, at 14:38 CDT, Timo Heister > wrote: > > > Hey all, > > > > the AUTHORS file for a specific release (see > > >

[deal.II] Re: making a package of PETSc vectors

Dear Itomas, I would recommend going the route suggested in this recent post , namely creating a vector of shared pointers of PETSc vectors, i.e. std::vector. Using shared pointers means that you safeguard against

[deal.II] Re: Vertices constraints inside the domain

Hi Seven, Thanks for reporting back that you missed a step in the application of the constraints! I'm glad that you managed to solve your problem. Best regards, Jean-Paul On Friday, March 24, 2017 at 2:09:35 AM UTC+1, seven wrote: > > Guess I figured it out. I didn't do >

Re: [deal.II] Re: AMR , how to pass solution vector to refined mesh

Hi Jaekwang, No, you've misunderstood in that I was just showing that to you as an example. You don't need to use that exact Vector class. You were nearly at the answer with what you've posted - you just need to read the compiler error more carefully to understand what its telling you is

Re: [deal.II] Re: AMR , how to pass solution vector to refined mesh

Dear Jaekwang, Step-31 demonstrates how to use the SolutionTransfer class with BlockVectors. In short, you need to specify the vector type as a template argument to the class. Here's how its done in that tutorial:

Re: [dealii-developers] Code DOI's via Zenodo

Thanks for the replies thus far. Interesting points that you both have raised. I was only introduced to Zenodo this last week and have just created an account, so I wasn't fully aware of how it could / would have to be used. To put this in context, Andrew and I were having a discussion related

[deal.II] Re: Installation using Spack fails during 'ncurses' installation

Dear Stephen, Since this is an issue related not directly to deal.II but rather Spack itself (ncurses is only a dependency of a dealii related package), I would suggest that you post your question on their forum . You'll generally get a quick

[deal.II] Re: Can't build deal ii tutorials or program which uses deal ii libraries due to unresolved external symbol _compress2 and _compressBound errors

Hi Michael, That output looks very strange. Which operating system and compiler are you using? Kind regards, Jean-Paul On Wednesday, March 15, 2017 at 2:31:54 PM UTC, mbranag wrote: > > Hi all, > > I am new to trying to work with deal II and have had trouble getting it > working. I currently

[deal.II] Re: Interaction with the boundary description for a parallel distributed triangulation

Dear Seyed, I assume there is a mistake within the documentation of > parallel::distributed::Triangulation class. Below the > "detailed description" part within the second box there is written > . Doesn't it have to be ? > Yes, this looks like a copy-paste error in the

[deal.II] Re: Access specific element within a distributed triangulation

Dear Seyed, > Extra question: Can we store variables or copy them to all processors? > Since I am filling a variable in a locally owned cell, currently on rank 3. > Then my other ranks, especially the root rank 0 has no clue of the values > which are set. Hence, there has to be a possibility

Re: [deal.II] Re: Announcing the deal.II Code Gallery

removed all the CG examples except for > goal_oriented_electroplasticity and my own and it worked I guess it is > one of the CG examples.. It takes an painfully long time to write the html > on my puny macbook air :) > > - Mike > > On Tuesday, March 7, 2017 at 11:54:42

Re: [deal.II] Re: Announcing the deal.II Code Gallery

5:34:39 PM UTC+1, Wolfgang Bangerth wrote: > > On 03/07/2017 09:30 AM, Jean-Paul Pelteret wrote: > > > > Matthias, is there any way to disable the deletion of doxygen.log when a > > build of the documentation fails? > > In doc/doxygen/CMakeLists.txt, line ~230,

Re: [deal.II] Re: Announcing the deal.II Code Gallery

e deletion of doxygen.log when a build of the documentation fails? J-P On Tuesday, March 7, 2017 at 4:28:00 PM UTC+1, Michael Harmon wrote: > > Thanks! I am glad it wasn't just me!! > > Mike > > On Tuesday, March 7, 2017 at 10:26:43 AM UTC-5, Jean-Paul Pelteret wrote: >> &g

[deal.II] Re: any suggestion how to run same code repeatedly with different boundary condition ?

Hi Jaekwang, The error message is pointing you to the fact that when you call run() a second time you end up trying to rebuild the triangulation on top of the one that you have the first time run() was called. There are a few ways that you can work around this. Here are two suggestions: 1.

Re: [deal.II] ZeroBoundaryCondition when FESystem is used

Dear Kyusik, > /user2/hanks318/dealii/dealii_pre/examples/step-20/step-20.cc:575: error: > no matching function for call to > ‘project_boundary_values(dealii::DoFHandler<2, 2>&, dealii::ZeroFunction<2, > double>, dealii::QGauss<1>&, std::map std::less, std::allocator > >&,

[dealii-developers] Re: Announcing the deal.II Code Gallery

Wolfgang's answer to Michael's question from a duplicate post: > Just check out the code gallery git repository in a directory parallel to > the > examples/ directory and build the deal.II documentation as described in > the > readme. It will pick up the code gallery and create joint

[deal.II] Re: Announcing the deal.II Code Gallery

Wolfgang's answer to Michael's question from a duplicate post: > Just check out the code gallery git repository in a directory parallel to > the > examples/ directory and build the deal.II documentation as described in > the > readme. It will pick up the code gallery and create joint

[deal.II] Re: How to output a single scalar in a parallel code

Dear Pasha, I must correct my answer by replacing "residual vector" by "internal force > vector" Ok, great. So this is a slightly different situation. I was going to say that I think that we're cross-talking here, and you saved me from sketching out a whole bunch of equations to clarify

[deal.II] Re: How to output a single scalar in a parallel code

* $Id: step-44.cc 30526 2013-08-29 20:06:27Z felix.gruber $ * * Copyright (C) 2010 - 2013 by the deal.II authors and * & Jean-Paul Pelteret and Andrew McBride * * This file is part of the deal.II library. * * The deal.II library is free sof

[deal.II] Re: Access specific element within a distributed triangulation

Hi Seyed, Nope, like I said, there's no such thing as a cell number in deal.II (at least in the sense that a cell knows its own "id" number). The cell->id() function returns a CellId

[deal.II] New: Physics module and solid mechanics code gallery example

Dear all, It is my pleasure to announce the inception of a Physics module in the deal.II project. This module, and its associated namespaces, is dedicated providing some core functionality for computations commonly

[deal.II] Re: Access specific element within a distributed triangulation

Dear Seyed, There are no cell "numbers" in deal.II, only CellIDs to give some unique identifier to each cell. So its unclear to me as to exactly what you're trying to achieve here. Are you wanting the fourth cell iterator for

[deal.II] Re: Neumann vector conditions

Hi Franco, Great, I'm glad that you managed to work it out! Best, Jean-Paul On Wednesday, February 22, 2017 at 12:58:45 PM UTC+1, Franco Milicchio wrote: > > Thanks guys, I've succeeded in making a full 3D example with your > suggestions. > > -- The deal.II project is located at

[deal.II] Re: hp::DoFHandler does not support parallel::distributed::Triangulation

Hi Zhenlin, I concur with Denis - I regularly use the method that he's outlined in conjunction with hp::DoFHandler. Regards, Jean-Paul On Wednesday, February 22, 2017 at 9:53:26 AM UTC+1, Denis Davydov wrote: > > you can always partition regular triangulation by >

[deal.II] Re: Neumann vector conditions

Dear Franco, Super quick answer: Step-44 demonstrates how to implement the Neumann BC for elasticity . Best, Jean-Paul On Thursday, February 16, 2017 at 6:22:06 PM UTC+1, Franco Milicchio wrote: > > Dear

[deal.II] Re: installation problem

Dear Dip, The clue is in the message you posted: cannot create directory: /usr/local/share/deal.II/scripts. Maybe need > administrative privileges. You can try to set the install prefix to another directory that you have write access to, such as your home directory. I hope that this helps.

[deal.II] Re: Approximate Derivative Tensor functionality

Dear Sumedh, The following works for me with version 8.4.1. For some reason it is necessary to supply some template arguments to this function - this could probably be improved. I'll open an issue about this. #include #include #include #include #include #include #include using

[deal.II] Re: Approximate Derivative Tensor functionality

Hi Sumedh, The highlighted parts look suspicious: DerivativeApproximation::approximate_derivative_tensor(dof_handler, solution, cell, cell_grad, unsigned int); DerivativeApproximation::approximate_derivative_tensor(dof_handler, solution, cell, cell_hessian, unsigned int); You

[deal.II] Re: neighboring faces on the boundary

> > Since Erik explicitly asks for a way to "get the degrees of freedom living > on the set of faces", I would still just modify the referenced code to > return face_iterators and access the corresponding DoFs using them. > You're 100% correct, I misread the question (well, rather I focussed

Re: [deal.II] Synchronization issue for parallel computation of material forces

Dear Seyed, Daniel’s been nice enough to furnish you with more information, but at this point one of your deleted comments is quite telling to me: > Any ideas what could cause such a behavior? I am really not an expert yet to > dive deeply inside the deal.II parallel structure. As we explain

Re: [deal.II] Re: Synchronization issue for parallel computation of material forces

Seyed, Thats a compile-time error, not a run-time error. I bet that your output_results() function is marked as const, so you cannot modify the configurational_forces vector unless its mutable. But if you have any doubts, stick to what’s done in step-40. I’m not particularly familiar with the

[deal.II] Re: cannot call member function ‘void tbb::task::spawn(tbb::task&)’ without object

Dear Lev, Can you please post your configuration and installation log files (`summary.log` and `detailed.log`)? Regards, Jean-Paul On Tuesday, January 31, 2017 at 4:47:30 AM UTC+1, Lev Karatun wrote: > > Hi, > > I was trying to install (to an empty directory) the newest version of > dealII

[deal.II] Re: bool ParameterHandler::read_input (const std::string &, const bool, const bool, const std::string &) DEAL_II_DEPRECATED

Dear Vinayak, You must be using the developer version, right? This function has been deprecated and, I believe, is superseded by the function ParameterHandler::parse_input . I hope

[deal.II] Re: question about a lage deformation model based on the updated Lagrangian foemolation

e.g. Perhaps the mesh strategy I've sketched out *might* be more appropriate? On Friday, January 27, 2017 at 11:28:59 AM UTC+1, Jean-Paul Pelteret wrote: > > Hi H.B, > > I suppose its not entirely surprising, because performing local mesh > refinement doesn't really address

[deal.II] Re: question about a lage deformation model based on the updated Lagrangian foemolation

figure > demonstrates the mesh with adaptive h-refinement. > > > On Thursday, January 26, 2017 at 12:23:09 AM UTC+3:30, Jean-Paul Pelteret > wrote: >> >> Dear H.B. >> >> For this mesh and deformation field, you can expect to run into this >> problem r

[deal.II] Re: Assembly of material forces

Dear Seyed, On top of what Wolfgang has already said, I have a few more direct comments about what you posted a few days ago. > The computation of configurational forces is accomplished by the following > formula: > > > >

Re: [deal.II] Re: Add heterogeneous parameters controlled by function on cells

day, January 25, 2017 at 2:47:18 PM UTC+1, Wolfgang Bangerth > wrote: >> >> On 01/25/2017 05:37 AM, Jean-Paul Pelteret wrote: >> > Dear Lam, >> > >> > There are a number of ways that you can do this. One approach would be >> to >> >

[dealii-developers] Re: Copyright years during pull request review

Thanks for the info, Wolfgang! I didn't know about this great feature :-) On Thursday, January 26, 2017 at 12:07:45 AM UTC+1, Wolfgang Bangerth wrote: > > > All, > we've had a few emails over time where, during patch review, people > comment on copyright years in tests or other files they

[deal.II] Re: question about a lage deformation model based on the updated Lagrangian foemolation

Dear H.B. For this mesh and deformation field, you can expect to run into this problem regardless of whether you use the total or updated Lagrangian formulation. As you can see, with your updated formulation you run into an issue when the mapping Jacobian becomes singular (due to element

[deal.II] Re: Assembly of material forces

Dear Seyed, > My problem is not the theory. > Providing the theory is for our benefit (and therefore yours). No one here is necessarily an expert in what you're trying to accomplish. So, for all of your explanation, an equation or two might go a long way to help us understand exactly what

[deal.II] Re: Add heterogeneous parameters controlled by function on cells

Dear Lam, There are a number of ways that you can do this. One approach would be to define a class that derives from the function class ; this is alluded to in step-8

[deal.II] Re: discontinuity and overlap of elements in 2D thermoelasticity problem using quadratic elements

Dear Anup, Its possible that this is related to this issue . Do you perhaps have a minimal test case that reproduces the problem? Best, Jean-Paul On Saturday, January 21, 2017 at 4:07:00 AM UTC+1, Anup Basak wrote: > > Hello all, > > I have solved

Re: [deal.II] Re: How to solve a linear system with two RHS and a same matrix?

r time and consideration > Pasha > > On Wednesday, January 18, 2017 at 4:59:44 PM UTC+3:30, Jean-Paul Pelteret > wrote: >> >> Great, thanks a lot. I've added it to the issue >> <https://github.com/dealii/dealii/issues/3821> on GitHub that I opened >>

Re: [deal.II] Re: How to solve a linear system with two RHS and a same matrix?

Great, thanks a lot. I've added it to the issue on GitHub that I opened this morning. So clearly the problem is elsewhere. Have you tried passing a normal MPI::Vector to the Eulerian map instead of the MPI::BlockVector that you had used in the

Re: [deal.II] Re: How to solve a linear system with two RHS and a same matrix?

::MPI::Vector> > q_mapping(1, dof_handler, rel_solution2.block(0)); > > > Thank you > Pasha > > On Wednesday, January 18, 2017 at 1:07:48 PM UTC+3:30, Jean-Paul Pelteret > wrote: > Dear Pasha > > I think that there are two problems with how you'v

Re: [deal.II] Re: How to solve a linear system with two RHS and a same matrix?

or5printERSojbb+0x126) > > [0x7fd462513f60] > [pasha:03624] [21] > ./FEM(_ZN3FEMILi2EE26assemble_large_deformationEb+0x2327) [0x560017] However, maybe this is not the case and some else has some other ideas. On Wednesday, January 18, 2017 at 10:37:48 AM UTC+1, Jean-Paul Pelteret

[deal.II] Re: Computation of shape function gradients at the reference cell

Dear Tulio, This is the type of information that you can get directly from the chosen FiniteElement, e.g. this function provides the shape function gradient on the unit cell. You could

[deal.II] Re: How to solve a linear system with two RHS and a same matrix?

Dear Pasha, At first glance, it would appear that there is a further ConstraintMatrix::distribute_local_to_global function designed with this in mind. It takes in the local_matrix but

Re: [deal.II] Re: Elastic energy computation

Dear Seyed, These two things are very different, and cannot be compared with one another. The “strain” in the assembly routine stems from the weak form, which is presented in the introduction to the tutorial. If one considers a variational approach, is coincides with the variation of the

[deal.II] Re: Elastic energy computation

Dear Seyed, There are two get_strain() functions in step-18. The first computes the symmetric part of the shape function gradients, and the second computes the small strain tensor. To store the values of the

Re: [deal.II] Examples makefile

Dear Victor, CMake has some facilities to add to the link line. Here are a couple of stackoverflow posts

Re: [deal.II] Re: interpolate_to_different_mesh produces strange results

l give a better (although still not exact) visualisation of the approximated solution field. J-P On Thursday, January 12, 2017 at 9:43:46 PM UTC+1, Wolfgang Bangerth wrote: > > On 01/12/2017 06:45 AM, Jean-Paul Pelteret wrote: > > > > That said, it does seem a bit s

[deal.II] Re: interpolate_to_different_mesh produces strange results

Hi Krzysztof, I don't have a direct comment on the result that you've shown here, but I think it would be useful if you mentioned what type and order of FE you are using here. One thing that you should be aware of is that Paraview does not interpolate data in the same way as deal.II does, so

[deal.II] Re: Relationships between material parameters

Dear Seyed, It would be great to have your contribution to deal.II! When you have the time to implement this, open up an issue on the GitHub page and we could discuss this further. We can always refer back to this conversation at that point in

[deal.II] Re: Discontiuities in material properties

Dear Bjorne, There are quite a number of examples of Laplace and Poisson problems in deal.II's tutorials . The picture that you've shown could well be produced by a derivative of step-6

Re: [deal.II] Re: Relationships between material parameters

I am most swayed towards Wolfgang's suggestion that takes in some identifying enumeration type and the associated material parameters. I think its probably the most transparent and easy to maintain option that we've come up with thus far. Seyed, would you like to try to implement this?

Re: [deal.II] Re: Relationships between material parameters

Constitutive_Parameters::Bulk_modulus::from_lambda_and_mu(double lambda, double mu) This can get untidy quite quickly, but I can’t think of a much better alternative… Best, J-P > On 10 Jan 2017, at 14:07, Wolfgang Bangerth <bange...@colostate.edu> wrote: > > On 01/10/2017 04:21 AM, Jean-Paul

[deal.II] Re: Relationships between material parameters

Dear Seyed, There is a table in wikipedia that details how to convert between fundamental elastic material parameters. Due to the number of permutations that are available, I would be hesitant to add this to deal.II itself. However,

[dealii-developers] Building deal.II with ccache

Dear all, I've recently become aware of ccache , although I have no experience with it whatsoever. Is this something that may benefit us when it comes to recompiling deal.II during development? It looks like it might be quite easy to integrate

[deal.II] Re: cout stiffness matrix in step-3

Dear Michael, There are a number of "print" functions in the sparse matrix classes. See the answer to this question , as well as some of the surrounding discussion for more details.

[deal.II] Re: Evaluating the gradient of the solution at the centroid of the element

ient than the dilatation element because for each element I just > need to calculate one quantity instead of solving a linear system to remove > the static condensation from the displacement system. > > On Thursday, December 22, 2016 at 11:22:40 AM UTC-5, Jean-Paul Pelteret &

[deal.II] Re: Evaluating the gradient of the solution at the centroid of the element

Firstly, a tangential observation: For the mean dilatation element (Q1-P0-P0), the dilation and pressure variables can be condensed out on an element level and a modified one-field formulation remains. For this element the "mean dilatation" means that one must compute \bar{\theta} = 1/V_{e} *

[deal.II] Re: deal.II FE structure

Dear Seyed, You may also be interested in looking at the module on the interplay between finite elements and mappings , and the description to the mapping class. Note that

Re: [deal.II] Re: BlockSparseMatrix and BlockVector with a nested hierarchy of blocks

Hi Oded, Have you managed to get anywhere with this? I have no particularly creative suggestions for this issue. The only thing I can think of is to derive a new class from SparseMatrix, which would contain your BlockMatrixArray as a member variable, and work with that. There is also the

[deal.II] Re: internal compiler error: recipe for target 'source/numerics/CMakeFiles/obj_numerics.debug.dir/all

Dear ExcitingDDT, It may be possible that you've run out of system resources on the VM during compilation. How much RAM have you allocated to this VM image, and are you compiling with multiple threads? Regards, Jean-Paul On Monday, December 19, 2016 at 2:17:03 PM UTC+1, exciting...@gmail.com

[deal.II] Re: Computation of B-operator

There are additional checks, warning and error messages that are processed in debug mode. So they're specifically in place to help detect problems like you're having. For this reason it is *highly* recommended to do your development in debug mode. This is mentioned numerous times in the

Re: [deal.II] Re: ifem

Dear Joaquin, As a supplement to Luca's message, with every release of deal.II there is the possibility that we introduce some incompatibilities that break existing code. This is what must have happened here - I assume that you've upgraded from version 8.2.1 or earlier to something newer, and

[deal.II] Re: make test

Dear Sudarshan, Could you please post the other log files, namely "detailed.log" and "summary.log". If the experience of previous posters with MPI problem is anything to go by then you've either (1) got a broken MPI installation, or (2) have compiled one or more of deal.II's dependencies using

Re: [deal.II] Re: Problem with installation

Dear Sudarshan, I see that you've posted this question already in as a new topic . Since you've made that post, lets rather keep keep the discussion there. Regards, Jean-Paul On Friday, December 16, 2016 at 1:27:24 PM UTC+1,

[deal.II] Re: deal.II cmake stuck at "Performing Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG"

Dear Praveen, Unfortunately I don't have any suggestions about CMake hanging. I've just reinstalled deal.II through Spack on both my Apple and Linux machines and I didn't run into the problem you're experiencing. Denis has some experience with installing deal.II though spack on a number of

Re: [deal.II] Re: ifem

Dear Joaquín, >From your previous posts I assume that all of PeFT, Pe[qs] and F[qs] represent rank 2 tensors. If this is correct then no, the contraction indices that you've specified are not correct. They're out of the range [0,1] that are valid for rank-2 tensors, and this would presumably

[deal.II] Re: Tensor output via ConditionalOStream pcout

Dear Seyed, Thanks for sharing your print function. For future reference, the FullMatrix class has two print

[deal.II] Re: BlockSparseMatrix and BlockVector with a nested hierarchy of blocks

Dear Oded, I think that the BlockMatrixArray class might offer the functionality that you're looking for? If so then I'm not quite sure what the equivalent class for the BlockVector would be. If there is none, then you

Re: [deal.II] square pyramid boundary

Dear Loylick, Great, I'm glad you've managed to create a grid using the merge function. The way that you've specified the boundary id's is typically fine. The other function sets the boundary id's of both the faces and edges, which is unnecessary for most cases. Regards, Jean-Paul On

Re: [deal.II] square pyramid boundary

Dear Loylick, For these more complex grids that are not defined in GridGenerator, you have a few options. You can: 1. Use other GridGenerator functions in conjunction with the GridGenerator::merge_triangulations

[deal.II] Re: Tensor output via ConditionalOStream pcout

Yes, well TrilinosWrappers::SparseMatrix only has a print() function. I took from what you wrote about that you were using dealii:: SparseMatrix. As could be expected, you

[deal.II] Re: Tensor output via ConditionalOStream pcout

Dear S. A. Mohseni, >From the class documentation , I figure that you should be able reach the equivalent output with (something like) the following steps: if (pcout.is_active()) { system_rhs.print(pcout.get_stream());

[deal.II] Re: general question

> > For 2D (plane strain, plane stress and axisymmetric) and 3D the 1.0/3.0 > should be used (not 1/dim). > Good point! Special consideration definitely must be made for the axisymmetric / plane stress / plane strain cases. Cheers, J-P -- The deal.II project is located at

Re: [deal.II] deal.ii workflow?

Dear Michael, It could definitely be overwhelming if you dive straight into an advanced application using deal.II, and is certainly not advised! Your options for information resources are listed in this post . A general

Re: [deal.II] Re: GitHub: make developers team public and add @dealii to ping all

Maybe you also don't have rights on the other group, ha ha :-) On Tuesday, December 6, 2016 at 6:26:27 PM UTC+1, Wolfgang Bangerth wrote: > > On 12/06/2016 10:14 AM, Jean-Paul Pelteret wrote: > > Don't you have the little "move" button at the top of the post (see > &g

Re: [deal.II] Re: GitHub: make developers team public and add @dealii to ping all

06/2016 09:49 AM, Jean-Paul Pelteret wrote: > > Oh, actually Wolfgang could probably move it - I don't have write access > to > > the developer forum. > > Nope, can't do -- completely separate mailing lists... > > -- > --

[deal.II] Re: GitHub: make developers team public and add @dealii to ping all

Oh, actually Wolfgang could probably move it - I don't have write access to the developer forum. On Tuesday, December 6, 2016 at 5:47:36 PM UTC+1, Jean-Paul Pelteret wrote: > > No way to move it, but I can delete it if you want? > > On Tuesday, December 6, 2016 at 5:41:32 PM UTC+1, D

[deal.II] Re: GitHub: make developers team public and add @dealii to ping all

No way to move it, but I can delete it if you want? On Tuesday, December 6, 2016 at 5:41:32 PM UTC+1, Denis Davydov wrote: > > wrong forum, sorry, i meant to post it here > https://groups.google.com/forum/?fromgroups#!forum/dealii-developers > If there is a way to move the post, feel free. > >

Re: [deal.II] Re: Modeling Stokes flow in and around a droplet using the approach of step-46

Dear Oded, I believe that Wolfgang has answered your question in much more detail and much more precision than I would have, so I think that there's no need for me to elaborate on further on what I said. Regards, J-P On Monday, December 5, 2016 at 5:47:17 PM UTC+1, Oded Yaakobi wrote: > > Hi

Re: [deal.II] Re: Modeling Stokes flow in and around a droplet using the approach of step-46

Hi Oded, Is this the recommended way to address point a), or is there another way > which is better? > I don't work primarily in fluid-mechanics, so this is a bit out of my field of knowledge (and comfort zone) and I'm going to defer to other's wisdom here. I suppose you're uncomfortable that

Re: [deal.II] Re: Apply Neumann Boundary condition

Dear Benhour, > These are 9 concepts, in 9 lines of text, all without any kind of > elaboration. > In other words, we have no real idea what you are doing, and equally > important, we have no idea what is actually wrong. When debugging problems > like yours, you need to learn to reduce

[deal.II] Re: Distorted cell when it is crated by gmsh

Dear Kyusik, The error message that deal.II has outputted explains what the problem is: > However, this is an internal line not located on the boundary. You cannot > assign a boundary indicator to it. You cannot give a boundary indicator value to internal lines/faces. If appropriate, you can

Re: [dealii-developers] Promoting developer version documentation in search engines and user forum posts

Hi Bruno, That makes sense, and is another tick for the "use the latest release" column :-) Thanks, J-P -- 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

Re: [dealii-developers] Promoting developer version documentation in search engines and user forum posts

Hi Toby, I still use grep locally for this, although I also use the doxygen search > tool too. > Thats a good idea, if you know exactly what phrase you're looking for. Sometimes I can't think of the correct term and need to paraphrase and thats why a search engine is more useful for this

<    1   2   3   4   5   6   >