[deal.II] Re: Untraceable "not implemented" error in GDB

Yep that does it! Thanks for your patience :) On Friday, September 16, 2016 at 7:28:41 PM UTC+2, Bruno Turcksin wrote: > > Alex, > > before the run command, you need to use: catch throw > > Best, > > Bruno > > On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote: >> >> A

Re: [deal.II] Help with Vector template instantiations

True, I've checked in the master and it is templated for the Function too. I use 8.4.1. It's fine then. Thanks. On Friday, September 16, 2016 at 5:39:33 PM UTC+1, Wolfgang Bangerth wrote: > > On 09/15/2016 05:12 AM, dragn...@gmail.com wrote: > > > > One more question, in fact a

[deal.II] Re: Untraceable "not implemented" error in GDB

Alex, before the run command, you need to use: catch throw Best, Bruno On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote: > > A couple of times now I have encountered GDB output similar to my attached > snapshot. > > The previous time I had only made a very small change

Re: [deal.II] Help with Vector template instantiations

On 09/15/2016 05:12 AM, dragniko...@gmail.com wrote: One more question, in fact a small inconsistency that is of my interest: the function VectorTools::interpolate_boundary_values is not templated for the generic Number type but for double only (argument

Re: [deal.II] Re: Failing to set up simple test configuration

Timo, when I looked into this before posting my question, it seemed to be a pretty clear issue with the perl command not working on the Windows filesystem. Per my recent reply to Wolfgang, I have moved forward with a simple work-around (which simply does not involve running ctest on the

Re: [deal.II] Re: Failing to set up simple test configuration

Wolfgang, thanks for pointing me to this part of the code. I'm not sure when I'll try to fix the problem, because it was very simple to just only ever run ctest on the Linux filesystem, completely circumventing it. I'll make sure to post an update if I ever fix this so that I can run ctest on

[deal.II] Re: 1D version of step3

Bruno, Yeah, I noticed an old discussion with the same problem and solved it. Thanks, Weixiong 在 2016年9月16日星期五 UTC-5上午10:42:30，Bruno Turcksin写道： > > Weixong, > > On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote: >> >> When running the program, the solution is zero on

[deal.II] Re: 1D version of step3

Weixong, On Friday, September 16, 2016 at 11:35:09 AM UTC-4, Weixiong Zheng wrote: > > When running the program, the solution is zero on the left side as > expected. However, the right side solution is something nonzero. Since I am > using the same apply_boundary_condition settings, I am

[deal.II] 1D version of step3

Dear all, I just tried to modify step-3 to 1D. The changes are minor. The equation is changed to be with a small reaction. The mesh is generated with subdivided_hyper_cube (triangulation, 50, 0, 10); I changed all the <2>, the dimension, to <1>. When running the program, the solution is zero

Re: [deal.II] Parasitic stress in corners with periodic boundary conditions

Hi, sorry for this late reply. I missed it and realized just now. I found the problem, which is simply that if the whole system is fully periodic ( I mean, for example from plane to torus topology) then the 4 corners become effectively fixed (the other possibility would be rigid body motion).

[deal.II] Re: CXX flags for SIMD and other optimization flags (GCC@6)

A useful flag that I use in release mode is -funsafe-loop-optimizations, which assumes that loop counters cannot overflow and other such things. I don't remember the exact numbers but I do remember that using this flag made a small, but measurable, performance improvement. On Thursday,

Re: [deal.II] Re: Help with time stepping methods

I have created a pull request here: https://github.com/dealii/dealii/pull/3123 Thanks again Bruno 2016-09-16 10:01 GMT-04:00 Bruno Turcksin : > 2016-09-16 9:22 GMT-04:00 Vaibhav Palkar : >> >> The error being exactly zero is indeed

Re: [deal.II] Re: Help with time stepping methods

2016-09-16 9:22 GMT-04:00 Vaibhav Palkar : > > The error being exactly zero is indeed intriguing. I'm still looking out for > the reason why that is happening. I didn't understand what you meant by a > "ramp in time". Could you please elaborate? Since you are using a

Re: [deal.II] Re: Help with time stepping methods

On Friday, September 16, 2016 at 1:38:57 AM UTC+5:30, Bruno Turcksin wrote: > I don't see anything wrong. The output says that your error is zero, > are you doing a simple ramp in time? It's very strange that the error > is exactly zero. What happens if you just use the default parameters? >

[deal.II] Re: How to find all the partial derivatives of the solution polynomial in deal.II

Jiaqi, Currently you can access first, second and third partial derivatives in FEValues. The FiniteElement class also implements fourth derivatives. If this is sufficient for your purposes, then using FEValues*::third_derivative should be fine for you. I don't see a easier way at the moment.