not even close. But I always found newtontr fiddly anyway:
it tends to be too trigger happy to shout "convergence" and finding the right
parameters to make it not-so-trigger-happy is hard.
Cheers,
Juha
--
--
Hi Jed,
Let's see what comes of this... I forked petsc/petsc and created a pull
request. There are probably loads of unneeded casts and at least one +1 just
to make sure I'm not rounding a float down into an integer under any
circumstances.
Thanks, the logic looks reasonable. Unfortunately,
--
---
| Juha Jäykkä, ju...@iki.fi |
| http://koti.kapsi.fi/~juhaj/ |
---
will never create a
local vector out of it and never do any MPI calls with it.
Bottom line: if the answer to my question above is yes, I would still prefer
a way which consumes less memory if there is an easy one.
Cheers,
Juha
Barry
On Nov 7, 2013, at 3:35 PM, Juha Jäykkä ju...@iki.fi
For comparison, 3.4.2 gives (from the previous email): 354 MiB for 1
rank, 141 for 2 ranks and 81 for 4 ranks, which is a LOT less. I
suspect this might have something to do with the DA - DMDA change?
Hmm, I wonder where you're getting your numbers from.
From /proc/self/stat, which (for me
be improved and adapt to PETSc coding conventions if necessary (at
least the #defines are in a funny place to keep the patch simple).
Cheers,
Juha
On Sunday 06 Oct 2013 12:24:58 Jed Brown wrote:
Juha Jäykkä ju...@iki.fi writes:
Argh, messy indeed. Are you sure you mean 65 k and not 64 Ki?
I was using
to do with the DA - DMDA change?
I still haven't got around testig Barry's branch, but hope to be able to do
that over later this week.
Cheers,
Juha
--
---
| Juha Jäykkä, ju...@iki.fi
On Tuesday 22 October 2013 05:06:02 Matthew Knepley wrote:
On Tue, Oct 22, 2013 at 3:57 AM, Juha Jäykkä ju...@iki.fi wrote:
Barry,
I seem to have touched a topic which goes way past my knowledge of PETSc
internals, but it's very nice to see a thorough response nevertheless.
Thank
you
myself having time to fix and test this in two weeks, but
3.4.4 should be doable. Anyone else want to fix the bug by then?
Cheers,
Juha
--
---
| Juha Jäykkä, ju...@iki.fi |
| http
, it
could be merged to 'maint' (thus v3.4.k for k=3) after testing.
I'll try to get something useful in. What's the timetable?
Cheers,
Juha
--
---
| Juha Jäykkä, ju...@iki.fi
by timetable was that when is the next 3.4.x due and
when do you need the fix if it is to go to the next release?
Cheers,
Juha
--
---
| Juha Jäykkä, ju...@iki.fi |
| http
On Sunday 18 August 2013 08:10:19 Jed Brown wrote:
Output uses a collective write, so the granularity of the IO node is
probably more relevant for writing (e.g., BG/Q would have one IO node
per 128 compute nodes), but almost any chunk size should perform
similarly. It would make a lot more
--
---
| Juha Jäykkä, ju...@iki.fi |
| http://koti.kapsi.fi/~juhaj/ |
---
signature.asc
Description: This is a digitally
memory on their HPC system.
Cheers,
Juha
--
---
| Juha Jäykkä, ju...@iki.fi |
| http://koti.kapsi.fi/~juhaj
.
Cheers,
-Juha
--
---
| Juha Jäykkä, ju...@iki.fi |
| http://koti.kapsi.fi/~juhaj/ |
---
signature.asc
--
---
| Juha Jäykkä, ju...@iki.fi |
| http://koti.kapsi.fi/~juhaj/ |
---
signature.asc
Description: This is a digitally signed message part.
indication that both acml and mkl are somehow broken? If it is, I will
Its likely that the breakage was the thing I refered to in the last mail.
Upgrading to
3.3 should fix it.
Unfortunately, it does not. The behaviour is still exactly the same (unless I
download blas/lapack during PETSc
Hi list!
Petsc3.2-p7, make test fails and at a closer look,
src/snes/examples/tutorials/ex19 gives:
orterun -n 1 ./ex19 -dmmg_nlevels 4 -snes_monitor_short -
on_error_attach_debugger
lid velocity = 0.0016, prandtl # = 1, grashof # = 1
[0]PETSC ERROR:
Is this complex? There was a problem with the complex dot product for some
BLAS. If this is the problem, you can reconfigure with
--download-f-blas-lapack.
Also, upgrading should fix it.
I did not specify the scalar type, so I assume it is real since configure says
--with-scalar-type=real or
Dear list,
I have a strange linking problem with libpetsc.so. After running 'make
PETSC_DIR=$(pwd) PETSC_ARCH=linux-gnu-cxx-opt all', the library looks like
this:
~ nm linux-gnu-cxx-opt/lib/libpetsc.so|grep SAMappingInitializePackage
0048b4fe T SAMappingInitializePackage
Can you send the complete configure.log to PETSc Maint
I was looking at the log myself, but as it is over 47000 lines long and I have
no idea what I am looking for, it is hopeless. There is one thing that I
notice, though:
Check c-support c++-support and other misc tests
Defined
http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMDAVecGetArrayD
OF.html
Thanks! I has managed to overlook his. Switching to use this solved my
problem. Sorry for taking a while to reply, though.
Cheers,
Juha
-- next part --
A non-text attachment was
Hi list!
I am trying to create a 3D DA such that I can use DMDAVecGetArray() and access
it using array indexing. I know how to get several dof in the DA and how using
a struct to access the members works, when the dof is determined at compile-
time (so accesses like array[1][2][3].member1[2]
I guarantee you this is not a bug. This stuff is used by thousands of
people every day.
That's what I thought, too.
Its very simple and old code. There is a misunderstanding somewhere in your
code about how this mechanism works. I suggest stripping down the code until
there are just two
Hi all!
I am at a loss: my vector entries get zeroed when I am not even using the
vector.
I have the vectors:
ierr = DACreateGlobalVector(lattice.da, Fields); CHKERRQ(ierr);
ierr = VecDuplicate(Fields, lattice.prev_state);
There is not an API. The TSRK implementation will be updated to accept a
user-provided table of coefficients like TSARKIMEX and TSROSW, but you
shouldn't need to access the coefficients except to view them, right?
Right. I just may need them for my boundary conditions: they depend on time
We pass in the time of the stage when your RHSFunction is called. If you
Right, how can I have missed that?!? Thanks.
haven't eliminated boundary conditions, your system is likely
differential-algebraic, in which case you can use the IFunction interface
Eliminated? I am not sure what you
What exactly are you using TAO to do?
I have a large scale minimisation problem related to the problem I am using
PETSc to solve. The PETSc code is independent, so I could have two PETSc's
around and use the older one for TAO, but that seems like a lot of hassle
without significant benefit.
Hi all!
I am having nasty problems with SNES. As you probably guess already, my result
is non-converging line search. I have a good candidate reason for this, but I
do not know how to fix it.
Jacobian should be fine: -snes_ls_type test gives nice small numbers (not
quite as small as I would
Its hard to say anything without knowing what equations are being solved.
I was expecting that, but the equation is rather long to write in ascii. I do
have a latex version somewhere that I can send if necessary. It is horribly
nonlinear, though, including a term like (d/dx f) * (d^2/dx^2) f.
As Matt notes you absolutely need to run with -pc_type lu
-ksp_monitor_true_residual -ksp_converged_reason to make sure that the
Why lu? I was running with bjacobi for whatever reason, which I no longer
recall. Probably gave the fastest convergence before introducing the horribly
nonlinear
What physical system does it represent and what sort of discretization are
you using?
Please see arXiv:0809.4303 for details. The equation is obtained from the
Lagrangian (4) by imposing cylindrically symmetric u with z and t appearing in
complex exponential in a certain way, which decouples
Hi list!
I keep getting strange errors when running a PETSc code:
[6]PETSC ERROR: - Error Message
[6]PETSC ERROR: Object is in wrong state!
[6]PETSC ERROR: Matrix must be set first!
[6]PETSC ERROR:
Hi list!
I have a small problem with running a TS program with -ts_type runge-kutta. It
keeps telling me
Very small steps: 0.00
from the very beginning and never gets anywhere. The programs works fine for
other TS types (well, at least euler, beuler, cn and gl).
I am out of ideas as to
[0]PETSC ERROR: Zero pivot row 1 value 1.90611e-13 tolerance 1e-12!
You have a singular Jacobian, which leads me to believe that your boundary
conditions are incorrect.
Thanks for the tip. I also found the following in the -info output:
[0] SNESLSCheckResidual_Private():
Yes, if your BC do not give at least a locally unique solution, then your
Jacobian will
be rank deficient and Newton breaks down. You can still try Picard, but I
recommend
understanding what you mean by a solution first.
Thanks for confirming. And for the suggestion to try Picard, but it
Hi all!
I have a problem with KSPBuildSolution. Either there is something wrong with
KSPBuildSolution or my with understanding of it. Most likely the latter. I
would think from the docs that KSPBuildSolution gives (in its last parameter)
the current estimate of the solution and that at the
SNESSolve uses a Newton method so the linear system is being solving for a
So the solution in the KSP should actually be identically zero for a
converged result?
defect. If the initial guess is zero, then it would normally pick up your
Dirichlet boundary conditions on the first iteration and
DIVERGED_LINEAR_SOLVE... None of the convergence tolerances seem to make
This is a problem. Run with -ksp_converged_reason to find out why it's
diverging.
Sorry, I looked at a wrong output. For the exact solution, it is the line
search, which fails. KSP converges with CONVERGED_RTOL, but
Since I got two emails before I could reply to one, I am replying to both
simultaneously.
It is a good idea to use -ksp_type preonly -pc_type lu to start until you
understand the problem.
Matthew: Thanks, but I still get diverging line searches.
Your Jacobian may be incorrect, try running
Yes, it is the most common place to make programming mistakes and the
symptoms you describe are typical.
Please let me double-check there has not been a misunderstanding here: the
problems I describe occur with the PETSc built-in FD Jacobian approximation,
not my own. Now, I realise this will
Hi!
I was wondering what's the status of DA_XYZGHOSTED? It seems to be implemented
for 1D DAs only. Putting the boundary data at inside (i.e. non-ghosted part)
of the DA is not very nice since it necessitates separate handling of the for-
loops on the ranks that happen to be on the physical
If you know the changeset id [or the app lines that belong to this
changeset] - I can take a look.
No need to, I already backported the change to 3.0.0-p8. Thanks anyway.
It is rather simple, really: one can simply replace 3.0.0-p8/gr2.c with
dev/gr2.c, provided one also adds the define
Hi all!
I noticed a bug in 3.0.0-p8/src/dm/da/src/gr2.c, which causes the DA vector to
be saved incorrectly into the hdf5 file.
However, this seems to be fixed in the latest nightly build, so my question
is, how usable is the nightly or when will the -p9 come out with working HDF5
DA saving
44 matches
Mail list logo
