Another issue I have is for the following code piece, where I basically
have to rescale every part of the solution by a different factor (due to
using unitless variables in the calculation):
const ComponentMask surface_A_mask = fe.component_mask(surface_A);
const ComponentMask surface_B_mask =
I wrote a small test program for solving a non-linear equation using the
RK4-solver implemented in deal.II, and assembling the right hand side using
the matrix-free framework (code is attached). Afterwards I wanted to check
the scaling behavior, after it should serve as a base for a larger
After additional tests I noticed that I'm not only overwriting the
target_component-component with the new values, but also the other
components, but with 0 instead. But instead I do not want to touch them.
How can I do that (if possible)?
Thanks!
Am Donnerstag, 27. Februar 2020 17:00:12 UTC+1
Yes, the lambda worked, thanks!
Am Donnerstag, 27. Februar 2020 17:00:12 UTC+1 schrieb Wolfgang Bangerth:
>
>
> > |
> > Functions::InterpolatedTensorProductGridData
> interpolator(this->coordinate_values,
> >
>
39:23 UTC+1 schrieb Wolfgang Bangerth:
>
> On 1/23/20 7:29 AM, 'Maxi Miller' via deal.II User Group wrote:
> >
> > Why would you want to project when you can interpolate? That seems
> > unnecessarily expensive :-)
> >
> > I would like to have the
as I can see) nothing which can be used by others, I decided to delete the
question. Therefore, the original question is not relevant anymore, either.
Thanks!
Am Mittwoch, 29. Januar 2020 23:19:50 UTC+1 schrieb Wolfgang Bangerth:
>
> On 1/20/20 7:59 AM, 'Maxi Miller' via deal.II User Group
Am Mittwoch, 22. Januar 2020 19:23:52 UTC+1 schrieb Wolfgang Bangerth:
>
> On 1/22/20 11:17 AM, 'Maxi Miller' via deal.II User Group wrote:
> > As source term for calculations I am using data which is written in an
> > external matrix (because it has been calcula
As source term for calculations I am using data which is written in an
external matrix (because it has been calculated by an external function),
together with the x- and y-values for each matrix entry. My current
approach for using this data is to use an interpolation function from GSL,
and
As described in step-48 it is possible to use vectorized functions, such as
the function vdSin() from the MKL-library from Intel, together with
VectorizedArray-variables. Unfortunately I could not find any example about
how I can do that. Is the approach to simply use a code similar to
Found my mistake, I was iterating over the wrong things.
Am Sonntag, 19. Januar 2020 14:54:16 UTC+1 schrieb Maxi Miller:
>
> I added a small MWE-code to the question, to make debugging easier.
> Switching between the linear heat equation and the non-linear heat equation
> can be done using the
om/dealii/dealii/blob/b84270a1d4099292be5b3d43c2ea65f3ee005919/tests/matrix_free/pre_and_post_loops_01.cc#L100-L121
>> ?
>>
>> Best,
>> Daniel
>>
>> Am Sa., 18. Jan. 2020 um 12:05 Uhr schrieb 'Maxi Miller' via deal.II User
>> Group :
>&g
When applying the laplace operator to my solution vector, what is the
difference between forming an explicit matrix containing the laplace
operator by using
template
void LaplaceProblem::assemble_mass_matrix (){
TimerOutput::Scope t(computing_timer, "Mass matrix assembly");
Currently gather_evaluate is a replacement for the combination of
read_dof_values() and evaluate(), but it can not be used if one has to use
read_dof_values_plain() instead. Therefore I was wondering if it was not
implemented simply due to a lack of time, or because it is more difficult
to
I added a small MWE-code to the question, to make debugging easier.
Switching between the linear heat equation and the non-linear heat equation
can be done using the constexpr-variable use_nonlinear in line 79.
Furthermore, I changed the solution from exp(-pi^2*t) to exp(-2 * pi^2 *
t), and
x_free/pre_and_post_loops_01.cc#L100-L121
> ?
>
> Best,
> Daniel
>
> Am Sa., 18. Jan. 2020 um 12:05 Uhr schrieb 'Maxi Miller' via deal.II User
> Group >:
>
>> I tried implementing it as
>> data.cell_loop(::local_apply_cell,
>>
I tried implementing it as
data.cell_loop(::local_apply_cell,
this,
dst,
src,
//true,
[&](const unsigned int start_range, const unsigned
int end_range){
I.e. I should add an elementwise multiplication with the inverse mass matrix
vector as postprocessing function?
--
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
In step-48 the inverse mass matrix is applied by moving the inverse data
into a vector and applying the function scale(), i.e. as in the following
code:
data.cell_loop(::local_apply_cell,
this,
dst,
src,
I tried to implement a solver for the non-linear diffusion equation
(\partial_t u = grad(u(grad u)) - f) using the TimeStepping-Class, the
EmbeddedExplicitRungeKutta-Method and (for assembly) the matrix-free
approach. For initial tests I used the linear heat equation with the
solution u =
I tried to implement a solver for the non-linear diffusion equation
(\partial_t u = grad(u(grad u)) - f) using the TimeStepping-Class, the
EmbeddedExplicitRungeKutta-Method and (for assembly) the matrix-free
approach. For initial tests I used the linear heat equation with the
solution u =
either use a diagonal
> mass matrix (see step-48) or use the cellwise inverse as a preconditioner
> (when combined with suitable scaling) and solve the mass matrix iteratively.
>
> Best,
> Martin
> On 14.01.20 10:49, 'Maxi Miller' via deal.II User Group wrote:
>
> I could narrow it
vec.partitioner
$3 = std::shared_ptr (use count 3
, weak count 0) = {get() = 0x7a60c0}
i.e. no null ptr. Could the problem be there, or somewhere else?
Thanks!
Am Montag, 13. Januar 2020 21:41:54 UTC+1 schrieb Wolfgang Bangerth:
>
> On 1/13/20 8:41 AM, 'Maxi Miller' via deal.II User Group wr
I tried to implement a RK4-solver similar to the upcoming example 67 using
the matrix-free technique, and compare it to other solvers I wrote earlier.
For this purpose I chose the classical heat-equation for testing. When
running the attached example, though, I get a segfault when calling
I ran into several other compilation problems with that trilinos version,
thus I decided to try the suggested patch instead.
Am Donnerstag, 9. Januar 2020 16:31:21 UTC+1 schrieb Bruno Turcksin:
>
> Hi,
>
> This is a known problem with the development version of Trilinos
>
Hei,
when trying to compile deal.II with one of the latest Trilinos-Versions,
compilation fails with "fatal error: MueLu_CreateEpetraPreconditioner.hpp:
No such file or directory", but the configuration process goes through
without rising any problems. Which modules do I have to enable in
I tried to use the AD framework in my own codes (mainly for solving
nonlinear equations), and therefore wrote a small test program for solving
the linear diffusion equation (after I can calculate the jacobian by hand
for that equation). Thus, my residual for the AD-jacobian is -0.5 * (\nabla
Like this: https://github.com/dealii/dealii/pull/8899?
Am Freitag, 11. Oktober 2019 16:42:24 UTC+2 schrieb Wolfgang Bangerth:
>
> On 10/11/19 7:22 AM, 'Maxi Miller' via deal.II User Group wrote:
> > It is using the SolverControl-class for setting parameters such as the
> >
. Oktober 2019 07:35:41 UTC+2 schrieb Wolfgang Bangerth:
>
> On 10/9/19 7:47 AM, 'Maxi Miller' via deal.II User Group wrote:
> > This number already comes from solver_control, given as
> >
> > solver_control.last_step ();
>
> Hm, that's really quite unfortunat
This number already comes from solver_control, given as
solver_control.last_step ();
Am Montag, 7. Oktober 2019 15:33:29 UTC+2 schrieb Wolfgang Bangerth:
>
> On 10/7/19 5:32 AM, 'Maxi Miller' via deal.II User Group wrote:
> > I implemented the changes in step-36 suggested in
I implemented the changes in step-36 suggested in the tutorial for using
ARPACK instead of PETSc (as shown in the attachment). Now, the solver
reports a convergence in 4294967295 iterations (with correct result), thus
I assume a overflow/underflow bug. Is that something which I should report
> (In that case, no data is exchanged, and the vectors need to have
> compatible locally owned dofs before calling.)
>
> Best,
> Martin
> On 23.09.19 17:07, 'Maxi Miller' via deal.II User Group wrote:
>
> When doing that in my code, I get the error
> error: conversion from
When doing that in my code, I get the error
error: conversion from ‘Vector’ to non-scalar type ‘Vector<
float,[...]>’ requested
thus I assume I have to implement it myself...
Am Freitag, 13. September 2019 17:53:37 UTC+2 schrieb Wolfgang Bangerth:
>
> On 9/13/19 8:39 AM, 'Maxi
In my program I have to reuse old solutions (due to time dependency), but
would like to use them both as double values and float values
(preconditioning does not require double values). Unfortunately my old
solution is only given as a LinearAlgebra::distributed::Vector(),
but I have to use a
Ok, will do that, thanks!
Am Mittwoch, 11. September 2019 16:52:51 UTC+2 schrieb Wolfgang Bangerth:
>
> On 9/11/19 3:27 AM, 'Maxi Miller' via deal.II User Group wrote:
> > In one of my side projects I include the library deal.II, but use it
> > only for reading in parameter
In one of my side projects I include the library deal.II, but use it only
for reading in parameter files and printing out data in the HDF5 format. I
included it mostly because it is in use in most of my main projects, and
thus it already was available. Furthermore, being able to reuse parameter
u can not figure it out, can you make a minimal complete example I
> can try?
>
>
> On Tue, Aug 27, 2019 at 6:59 AM 'Maxi Miller' via deal.II User Group
> > wrote:
> >
> > I am trying to assemble my residual/RHS by using mesh_loop:
> >
I am trying to assemble my residual/RHS by using mesh_loop:
evaluation_point = present_solution;
extension_vector = newton_update;
extension_vector *= alpha;
evaluation_point += extension_vector;
residual.reinit(locally_owned_dofs, mpi_communicator);
I tried to implement a simple mixed-precision algorithm in deal.II, which
creates my matrix using float values, and my vectors using double values.
Unfortunately, the function distribute_local_to_global(cell_matrix,
cell_rhs, local_dof_indices, system_matrix, system_rhs) does not support
mixed
Following step-37 I tried to extend it for non-linear equations, using a
jacobian approximation for the "matrix" (which can be written as Jv = (F(u
+ ev) - F(u)) * 1/e, with e a small value (~1e-6), F() the residual of the
function, u the current solution, v the krylov vector obtained from the
Found my mistake, I forgot to call
mg_transfer.build(dof_handler);
before doing anything with it.
Am Donnerstag, 1. August 2019 09:02:15 UTC+2 schrieb Maxi Miller:
>
> Hei,
> the program crashes in release mode way before it crashes in debug mode.
> The code shown is completely from the
Hei,
the program crashes in release mode way before it crashes in debug mode.
The code shown is completely from the deal.II-library, with some added
std::cout<<-lines. The only code written by myself is in main.cc, but the
crash happens in the code from the library.
Am Donnerstag, 1. August
I am trying to implement a test program using the matrix-free method,
combined with a geometric multigrid preconditioner. In my case my
vmult/apply_add-function needs access to the solution from the last step.
Thus I added a vector
LinearAlgebra::distributed::Vector old_solution;
which is
Apparently you did not install the library correct, there is no *.so-file
in that folder. Maybe try to reinstall it?
Am Mittwoch, 31. Juli 2019 09:38:17 UTC+2 schrieb Javad Hashemi:
>
> Dear Dr. Bangreth,
>
> I really appreciate your email. I checked the lib folder and you can see
> the list of
I found my mistake, I could not reuse the same partition for the main
matrix and the MG-matrices, thus I had to add
LinearAlgebra::distributed::Vector local_solution;
mg_matrices[level].initialize_dof_vector(local_solution);
//local_solution = solution;
I followed step-37 for creating a MatrixFreeOperator, but now I also would
like to access a previous solution (which is needed during apply_add()),
and stored using a LinearAlgebra::distributed::Vector. In step-48 there is
an example which uses previous solutions, but here the solve-function is
/19 12:23 PM, 'Maxi Miller' via deal.II User Group wrote:
> > My LinearOperator only provides a vmult-interface, nothing else, but for
> > initializing the preconditioner I still need a sparse matrix, thus I can
> not
> > use the LinearOperator, as far as I understan
My LinearOperator only provides a vmult-interface, nothing else, but for
initializing the preconditioner I still need a sparse matrix, thus I can
not use the LinearOperator, as far as I understand. Or is there a way to
use it?
Am Mittwoch, 24. Juli 2019 17:28:14 UTC+2 schrieb Daniel Arndt:
>
>
vectors there. Given a
> nonlinear field u that you linearize about, you could perturb it with e*v_i
> and compute the local diagonal according to your formula. From what I
> understand, you have the operator in an even more abstract way, so
> collecting everything in one local
I am currently trying to implement the JFNK-method in the matrix-free
framework (by following step-37 and step-59) for solving nonlinear
equations of the form F(u)=0. The method itself replaces the multiplication
of the explicit jacobian J with the krylov vector v during solving with the
Is there then a way to use LinearOperator as Input for a preconditioner?
Else I still have to form the full system matrix (which I would like to
avoid).
Am Mittwoch, 24. Juli 2019 13:43:09 UTC+2 schrieb Daniel Arndt:
>
> On the other hand, would it be sufficient to unroll the
Am Mittwoch, 24. Juli 2019 00:39:14 UTC+2 schrieb Daniel Arndt:
>
> Maxi,
>
> No, that code is the vmult-call I am using in my LinearOperator (and is
>> used directly in my solve()-call). The calculate_residual()-function is
>> similar to the function in step-15, with the difference, that I do
the moving pulse. Is that possible?
The matrix I was mentioning earlier would be a dense matrix, formed
according to the DHT-method (i.e. no relation to FEM)
Am Dienstag, 23. Juli 2019 22:35:57 UTC+2 schrieb Wolfgang Bangerth:
>
> On 7/22/19 1:32 AM, 'Maxi Miller' via deal.II User Group
No, that code is the vmult-call I am using in my LinearOperator (and is
used directly in my solve()-call). The calculate_residual()-function is
similar to the function in step-15, with the difference, that I do not
provide alpha, but the vector, and return the calculated residual value.
Thus,
My aim is to implement the jacobian approximation, i.e. (if F(u) = 0 is the
function to solve) I wanted to implement
dst = (F(current_solution + epsilon * src) - F(current_solution))/epsilon.
In my LinearOperator, my code is
LinearOperator jacobian_operator;
jacobian_operator.vmult =
In my project I already managed to replace the system_matrix in the
solve()-call by a custom LinearOperator, but still I had to retain the
matrix itself (for the preconditioner, for example). Thus I am now trying
to use the MatrixFree-framework for that.
Thus, some questions arose:
- When
3
> Aquired function gradients on cell 3
>
>
> before crashing, indicating a problem on cell 1 1 0 3. As long as
> cell->active() is false, I can not call the function is_artificial() for
> checking if I am on an artificial cell. Is my if-loop correct, or did I
> miss so
On 7/12/19 11:28 AM, 'Maxi Miller' via deal.II User Group wrote:
> > It is difficult to write it as a single integral. The operation is
> similar to
> > the split-step fourier method, i.e. transforming the column vector f(r)
> once using
> > g(rho)=2\pi\int_0^\infty
nction is_artificial() for
checking if I am on an artificial cell. Is my if-loop correct, or did I
miss something here?
Am Freitag, 19. Juli 2019 18:01:03 UTC+2 schrieb Wolfgang Bangerth:
>
> On 7/19/19 9:59 AM, 'Maxi Miller' via deal.II User Group wrote:
> > What do the parallel m
mg,
mg_transfer);
and here I intent to replace all occurences of matrix_t with my custom
LinearOperator (if that makes sense).
Am Freitag, 19. Juli 2019 17:51:10 UTC+2 schrieb Wolfgang Bangerth:
>
> On 7/19/19 9:47 AM, 'Maxi Miller' via deal.II User Group wrote:
> > What I did w
...
Am Freitag, 19. Juli 2019 17:53:05 UTC+2 schrieb Wolfgang Bangerth:
>
> On 7/19/19 9:49 AM, 'Maxi Miller' via deal.II User Group wrote:
> > I can not use that function, else I will get
> > An error occurred in line <3543> of file
> > in function
> >
eitag, 19. Juli 2019 17:37:01 UTC+2 schrieb Wolfgang Bangerth:
>
> On 7/19/19 9:31 AM, 'Maxi Miller' via deal.II User Group wrote:
> > Based on the stacktrace the problematic access happens within
> mg_cell_worker():
> > ...
> > which is guarded by the if-condition.
&
What I did was the replacement of system_matrix with a function, providing
a vmult()-function. Now I would like to add a preconditioner based on that
function to reduce the necessary GMRES-iterations. But until now most of
the preconditioners require a matrix for initialization. Thus I wanted
Bangerth:
>
> On 7/19/19 9:18 AM, 'Maxi Miller' via deal.II User Group wrote:
> > Is it then possible to use this LinearOperator in a preconditioner? The
> code
> > works without one (i.e. PreconditionIdentity()), but the Iterations are
> > increasing quite fast, thus negat
p15::ScratchData<2>
const&, Step15::CopyData const&, unsigned int, unsigned int)
#13 ./MG_test: void
dealii::MeshWorker::mesh_loop, true> >, Step15::ScratchData<2>, Step15::CopyData,
dealii::TriaIterator,
true> >
>(dealii::TriaIterator,
true> > const&
Is it then possible to use this LinearOperator in a preconditioner? The
code works without one (i.e. PreconditionIdentity()), but the Iterations
are increasing quite fast, thus negating all speedup gained from the
LinearOperator.
I tried to find something in the examples, but only found data
I am trying to port example 15 to a MPI-supported version, using the
geometric multigrid method as preconditioner (to get more familiar with the
implementation). I followed example 50 while doing that, but currently I
get the error
An error occurred in line <3866> of file
I tried to follow the examples for setting up a LinearOperator (such as
shown in Step-22 and Step-20), but instead of a matrix I wanted to provide
my own function which should serve as vmult-function (i.e. a matrix-free
linear operator). Is that possible? My initial test was the following code:
> function-type object that can be used for evaluating the inverse of the
> Jacobians and the right-hand side.
> You might also want to have a look at the test base/time_stepping_01 (
> https://github.com/dealii/dealii/blob/master/tests/base/time_stepping_01.cc
> ).
>
> Best,
&
As far as I understand all implicit time-stepping methods in the
TimeStepping-namespace take a function which invert the jacobian matrix and
the mass matrix (combined). This is done using a sparse solver (UMFPACK).
Is it that still possible for a larger system (10kk DoFs), or do I have to
It is difficult to write it as a single integral. The operation is similar
to the split-step fourier method, i.e. transforming the column vector f(r)
once using
g(rho)=2\pi\int_0^\infty rf(r)J_0(2\pi\rho r)dr,
multiplying it with a vector, and transforming it back using
f(r) =
Is it possible to "mis-"use the facilities of deal.II for calculating a NLS
using the discrete hankel transformation? The idea here was to take an
evenly refined grid, and calculate the values of each node column based on
the values of the node column to the left/right times a constant matrix,
Yes, that works, thanks!
Am Donnerstag, 11. Juli 2019 17:01:21 UTC+2 schrieb Daniel Arndt:
>
> Maxi,
>
> Can you just try again with a recent commit?
>
> Best,
> Daniel
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
Something like this: https://github.com/dealii/dealii/pull/8307?
Am Donnerstag, 6. Juni 2019 00:38:59 UTC+2 schrieb Wolfgang Bangerth:
>
> On 6/5/19 3:22 PM, 'Maxi Miller' via deal.II User Group wrote:
> > is there a function for the elementwise multiplication of Tensors? I
>
Hei,
is there a function for the elementwise multiplication of Tensors? I could
only find functions for the scalar product, but not the schur product.
Thanks!
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
, it does not in the
> second, a != b
> I do not understand that behavior yet.
>
> Am Donnerstag, 30. Mai 2019 19:00:02 UTC+2 schrieb Wolfgang Bangerth:
>>
>> On 5/30/19 9:06 AM, 'Maxi Miller' via deal.II User Group wrote:
>> > I wanted to write some
!= b
Q(a)->B(b): Even though that worked in the first round, it does not in the
second, a != b
I do not understand that behavior yet.
Am Donnerstag, 30. Mai 2019 19:00:02 UTC+2 schrieb Wolfgang Bangerth:
>
> On 5/30/19 9:06 AM, 'Maxi Miller' via deal.II User Group wrote:
> > I wanted to
I wanted to write some functions to convert my solution from using
FE_Q-elements to FE_Bernstein-elements (and back). For that I wrote two
functions, convert_feQ_to_feB() and convert_feB_to_feQ() (as listed in the
attachment). When converting from FE_Q-elements to FE_Bernstein-elements, I
get
I/classFE__Bernstein.html#ad881d4e04f5e699e4a8bda5b4e9f5265
>
> that is impossible. Would an alternative solution be to interpolate
> everything onto a grid using FE_Q-elements, transfer the result, and
> interpolate the results back?
>
> Am Dienstag, 21. Mai 2019 03:
Dienstag, 21. Mai 2019 03:41:58 UTC+2 schrieb Wolfgang Bangerth:
>
> On 5/20/19 5:18 AM, 'Maxi Miller' via deal.II User Group wrote:
> > Trying to transfer solutions from an old grid to a new grid with
> > parallel::distributed::SolutionTransfer TrilinosWrappers::MPI::Vecto
Donnerstag, 16. Mai 2019 22:00:23 UTC+2 schrieb luca.heltai:
>
>
> > On 16 May 2019, at 9:16, 'Maxi Miller' via deal.II User Group <
> dea...@googlegroups.com > wrote:
> >
> > I would like to use the interpolate()-function to interpolate the
> correct function ont
That works, thanks!
Am Donnerstag, 16. Mai 2019 22:00:23 UTC+2 schrieb luca.heltai:
>
>
> > On 16 May 2019, at 9:16, 'Maxi Miller' via deal.II User Group <
> dea...@googlegroups.com > wrote:
> >
> > I would like to use the interpolate()-function to interpolat
Trying to transfer solutions from an old grid to a new grid with
parallel::distributed::SolutionTransfer> solution_transfer() and
solution_transfer.prepare_for_coarsening_and_refinement() fails with
An error occurred in line <71> of file <~/Downloads/git-files/dealii/source/
fe/fe_bernstein.cc>
i.e.
dirichlet-conditions on 0, neumann-conditions on 1, and similar stuff?
Thanks!
Am Donnerstag, 16. Mai 2019 19:20:59 UTC+2 schrieb Wolfgang Bangerth:
>
> On 5/15/19 8:37 AM, 'Maxi Miller' via deal.II User Group wrote:
> > I have to replace VectorTools::interpolate_boundary_v
'Maxi Miller' via deal.II User Group <
> dea...@googlegroups.com > wrote:
> >
> > I would like to use the interpolate()-function to interpolate the
> correct function onto my mesh for comparison during some simple tests. This
> works fine when using FE_Q-elem
I would like to use the interpolate()-function to interpolate the correct
function onto my mesh for comparison during some simple tests. This works
fine when using FE_Q-elements, but fails when using FE_Bernstein elements.
The error message I get is
An error occurred in line <3098> of file
I have to replace VectorTools::interpolate_boundary_values with
VectorTools::project_boundary_values at several places in my project. I
could apply the boundary values only for certain parts in my FESystem using
component masks, but I can not use those masks in
project_boundary_values(). What
When using FE_Q-elements as basis function, Lagrange-polynoms are used, as
far as I understand. Is it possible to replace those with B-splines as
basis functions?
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
I wanted to test the new ScratchData- and CopyData-Classes for DG-subfaces,
and thus used Test 3 with a locally refined grid. The result shows
significant distortions at the transitions between refinement levels.
Should that be, or is that a bug? Or is it just the missing handling of
subfaces
Am Dienstag, 30. April 2019 05:59:05 UTC+2 schrieb Wolfgang Bangerth:
>
>
> Maxi,
>
> > What did you have to do? I was going to reproduce your problem today
> by
> > installing a Trilinos version that has NOX enabled. Is this moot
> now,
> > i.e., was it a bug in your code or
Am Montag, 29. April 2019 22:36:55 UTC+2 schrieb Wolfgang Bangerth:
>
> On 4/29/19 7:35 AM, 'Maxi Miller' via deal.II User Group wrote:
> > Could get it to work, now the code works equally fine for one or several
> > MPI threads.
>
> What did you have to do? I was
result in "Convergence failed".
>>
>> Am Samstag, 27. April 2019 05:43:47 UTC+2 schrieb Wolfgang Bangerth:
>>>
>>> On 4/26/19 2:28 PM, 'Maxi Miller' via deal.II User Group wrote:
>>> > I think the current version is the smallest version I can get
ives a "Test passed",
> using more threads will result in "Convergence failed".
>
> Am Samstag, 27. April 2019 05:43:47 UTC+2 schrieb Wolfgang Bangerth:
>>
>> On 4/26/19 2:28 PM, 'Maxi Miller' via deal.II User Group wrote:
>> > I think the curre
m Samstag, 27. April 2019 05:43:47 UTC+2 schrieb Wolfgang Bangerth:
>
> On 4/26/19 2:28 PM, 'Maxi Miller' via deal.II User Group wrote:
> > I think the current version is the smallest version I can get. It will
> work
> > for a single thread, but not for two or more thread
After some tests it looks like as if the problem lies in the treatment of
the subfaces. When refining the grid globally, everything works as
expected, when refining adaptively, the ScratchData-Version fails. Thus I
assume the problem lies there, but I can not see it in the code?
--
The
I tried to rewrite step-12 using the recently introduced classes
ScratchData and CopyData. In the first iteration, the results are similar,
in the second iteration the new version gives wrong results, though. I
compared the generated matrices and right hand side vectors, and they were
:
>
> On 4/26/19 1:59 AM, 'Maxi Miller' via deal.II User Group wrote:
> > I tried to reduce it as much as possible while still being able to run,
> > the result is attached. It still has ~600 lines, but I am not sure if I
> > should remove things like the output-function? F
as
possible while removing unneccessary lines. Is that example usable?
Am Freitag, 26. April 2019 05:12:39 UTC+2 schrieb Wolfgang Bangerth:
>
> On 4/25/19 10:13 AM, 'Maxi Miller' via deal.II User Group wrote:
> > After running some tests, I ended up reducing the problem to the
After running some tests, I ended up reducing the problem to the transfer
to and from the Epetra-vectors. I have to write an interface to the model
(according to the instructions), and as shown in the code above. There I
have Epetra-Vectors created by my interface, with a size of
It looks as if you have to recompile Trilinos using the -fPIC-switch to
create position independent code.
Am Donnerstag, 25. April 2019 12:10:52 UTC+2 schrieb gabrie...@koeln.de:
>
> Hey everyone,
> I have an error at compiling deal_ii_with_Trilinos=ON, which I dont
> understand.
>
> First I
How exactly can I test the examples after modifying them, other than by
running them?
Am Sonntag, 7. April 2019 23:56:49 UTC+2 schrieb Wolfgang Bangerth:
>
> On 4/7/19 1:54 PM, 'Maxi Miller' via deal.II User Group wrote:
> > Could do that, but not until Easter (Dead
1 - 100 of 295 matches
Mail list logo
