[deal.II] Particles and field interpolation error

Dear all, I am playing with 9.2 and particles, but I've encountered a weird problem. If I remove a particle, the interpolated field on particle locations yields a wrong answer. My code does (now) everything by hand: // Here be drangons... Point<2> p_0(0.1,0.5); auto ref_cell_0 =

[deal.II] Re: Linker error with intel/19.0.5 on macOS Catalina

After some forum search, the workaround is horrible: *do not use Intel compiler* for Deal.II. PETSc and SLEPc compile and link just fine, but as it happens, the linking phase with Intel and Xcode is quite messy, and they do not support Xcode 11 or macOS Catalina, but hopefully, they will in

[deal.II] Linker error with intel/19.0.5 on macOS Catalina

Dear all, I have read the following posts on Intel's compiler version 19.0.5 on macOS Catalina 10.15.1: - https://groups.google.com/forum/#!searchin/dealii/intel$20compiler|sort:date/dealii/mmljxW1T4QQ/wOTR9SmiBgAJ - https://github.com/dealii/dealii/issues/8791 Now I can complete the CMake

Re: [deal.II] Step 31: Preconditioner correspondence

> Preconditioner design is hard -- which is why I've recorded 4 or so > lectures on the topic ;-) > > Thanks for your answer, Wolfgang, and I sure appreciate all the lectures! Cheers! Franco -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see

[deal.II] Step 31: Preconditioner correspondence

Dear all, As I am moving towards understanding the wrappers, I am facing a problem in making Step 31 converge. My previous question is answered, and it compiles. Yet, I am still wondering what kind of "pure deal.II" preconditioner I could use in that tutorial. Specifically, there are two in

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

Thanks Daniel, now it runs. Of course it won't converge, lacking preconditiones, but this is for another question. Thank you! Franco -- 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

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

> No unfortunately we don't have such things. However, most of the new > effort on linear algebra is in the LinearAlgebra namespace. > > Thanks, Bruno, I've started looking into that namespace. There are several options to make it work in a coherent way, I'll ask for comments on these

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

> > Thanks for your answer. By the way, would a wrapper for the Eigen > library be appealing to anyone? > I am sure it would be useful! > > Good to know, Bruno. I will start looking into those wrappers and I hope some student of mine will be helping (fingers crossed). Is there a small

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

> > Thanks for your answer. By the way, would a wrapper for the Eigen > library be appealing to anyone? > I am sure it would be useful! > > Good to know, Bruno. I will start looking into those wrappers and I hope some student of mine will be helping (fingers crossed). Is there a small

[deal.II] Re: Porting tutorials to PETSc from Trilinos

Thanks for your answer. By the way, would a wrapper for the Eigen library be appealing to anyone? And back to my lowly question :) I was able to port the Step 31 code to plain deal.II without PETSc, but I have an error at runtime. At the moment I removed the preconditioners and just used a

[deal.II] Re: Porting tutorials to PETSc from Trilinos

> > > step-40 tries to allow switching between Trilinos and PETSc as easy as > possible by using the deal.II/lac/generic_linear_algebra.h header and the > defining the LA::MPI namespace. > Thanks for your answer, Daniel. Even with that example I find it a little harder than I expected to use

[deal.II] Porting tutorials to PETSc from Trilinos

Dear all, I am trying to port the Trilinos examples, for instance Step-31, to PETSc. I am finding some difficulties, though, in the block matrix class, it seems a little bit different from Trilinos. In this function: template void BoussinesqFlowProblem::solve() { std::cout << "

Re: [deal.II] Eigenproblem with Multithreaded Code

wrote: > > On 6/17/19 6:10 AM, Franco Milicchio wrote: > > > > we're about to implement an eigenvalue problem that needs multiple > solutions. > > In particular, we're going to compute min & max eigenvalues of several > > matrices, so we were going

[deal.II] Eigenproblem with Multithreaded Code

Dear all, we're about to implement an eigenvalue problem that needs multiple solutions. In particular, we're going to compute min & max eigenvalues of several matrices, so we were going to spawn some threads and solve some in parallel. The problem is that, as far as I see, there are wrappers

[deal.II] Re: Avoid holding matrices in vector for MeshWorker

Thanks, Daniel, I modified the Assembler class to suit my needs. Franco -- 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

[deal.II] Avoid holding matrices in vector for MeshWorker

Dear all, I have seen that MeshWorker with the MatrixSimple assembler has an initialize member that needs a vector of matrices. However that isn't really good for my case, as I'd like to assign ownership of matrices as I wish, not necessarily to a vector. Is there any possibility to assemble

[deal.II] Re: MeshWorker clarifications

Just one more question about MeshWorker. I am trying to figure how I could assemble simultaneously more than one form. I've found that step 39 uses two different assemblers. My guess is that I could use a MatrixSimple assembler for bilinear forms, and ResidualSimple for linear forms. Is this

[deal.II] Re: MeshWorker clarifications

It was all my mistake in copy/pasting the weak form. The two matrices now are the same. Sorry for the noise. -- 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

[deal.II] Re: MeshWorker clarifications

Thanks for the answer, Daniel. On Monday, March 6, 2017 at 7:49:53 PM UTC+1, Daniel Arndt wrote: So my first question is, should I avoid using this class and implement >> parallel loops by hand (via TBB or other means)? >> > > "amandus"[1] is in fact based on MeshWorker. If you are trying to

[deal.II] MeshWorker clarifications

Dear all, I am trying to port the previous linear elastic code to MeshWorker, but I have some questions about this class. First of all, I have read this question , and I read that

Re: [deal.II] Neumann vector conditions

On Friday, February 17, 2017 at 1:48:54 PM UTC+1, Luca Heltai wrote: > > Dear Franco, > > I think there is a problem in your formulation… > > You are integrating > > u_i n_i f_i > > I agree I have a translation problem here. In practice, I am integrating a weak problem as this (in Fenics'

[deal.II] Re: Neumann vector conditions

On Thursday, February 16, 2017 at 7:49:52 PM UTC+1, Jean-Paul Pelteret wrote: > > Dear Franco, > > Super quick answer: Step-44 demonstrates how to implement the Neumann BC > for elasticity > > . >

[deal.II] Re: Recommendation: BCs in config

On Monday, February 13, 2017 at 3:09:20 PM UTC+1, Bruno Turcksin wrote: > > Franco, > > you could write everything into one string and then split it. So it would > like this: > > subsection bc > set value = 0.5*x+y; x*y^2 > end > > Take a look here >

[deal.II] Recommendation: BCs in config

Dear all, I want to have a series of functions read from an input file handled by the *ParameterHandler* class. These are the BCs of my problem, but I don't know how I could express them, since I'd like to have an unknown number of them. As far as I've understood, the parameters sections must

Re: [deal.II] ParameterHandler: MultipleSelection of couples

Thanks, Praveen. I could use those, and in my tests that I've done now they work great, but this means I won't be able to detect errors automatically. This deal.II feature is the best thing, dropping it would be not so cool. If not possible, I will just do this by hand. Thank you! Franco

Re: [deal.II] Is deal.II for me? Or, I got burned elsewhere

Thanks, this is really interesting! Franco On Monday, December 5, 2016 at 11:35:35 AM UTC+1, Luca Heltai wrote: > > On 2 Dec 2016, at 15:01, Bruno Turcksin > wrote: > > > > > > 2 - Are there facilities of some kind that can help in generating the > assembly code?

Re: [deal.II] Re: Is deal.II for me? Or, I got burned elsewhere

> There are no plan to add DSL. There has been some work on > LinearOperator that reduces the amount of work that needs to be > written but there is nothing planned in the future. > Ok, I will look into it. Thanks for all your answers! Franco -- The deal.II project is located at

[deal.II] Re: Is deal.II for me? Or, I got burned elsewhere

Thank you Bruno for your answers, I failed to mention that I use Fenics with C++, not with Python, sorry about that. I just have few points to ask, if you can bear with me. 1 - Is it truly thread-safe? As in running a single analysis, or running >> several (no data sharing), without problems.

[deal.II] Is deal.II for me? Or, I got burned elsewhere

Dear all, after a couple of years developing with Fenics on MacOS X, I stumbled upon two dreary problems: it won't provide binaries anymore, and it does not play well with multithreading. I was then thinking about switching to deal.II, but I hope you can help me in dispelling some doubts. My