public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Fabrice Rossi <Fabrice.Rossi@apiacoa.org>
To: gsl-discuss@sources.redhat.com
Subject: Re: Help: working with large gsl_vector
Date: Wed, 15 Dec 2004 11:12:00 -0000	[thread overview]
Message-ID: <41C01C1A.8060306@apiacoa.org> (raw)
In-Reply-To: <200412141510.28746.ntt@physics.ucla.edu>

Toan T Nguyen wrote:
> Hi, thank you for the analysis. Apparently, my analytical calculation is able 
> to guess the minimum reasonably good, so I need only 20000 iterations to find 
> the minimum. 

Nice!

> However, the strange thing is if I take the final minimized vector and run it 
> through the conjugate gradient routine again, the energy (my function to 
> minimize) keeps going down for a few more 1000s iterations (albeit it change 
> only the 4th significant digit). Do you know what's wrong?

It might be related to the restarting of the algorithm. A conjugate 
gradient calculates is descent direction thanks to the gradient at the 
current point and to the previously used direction. The first descent 
direction is (minus) the gradient alone. When you restart the algorithm, 
it will use the gradient rather than the descent direction it should 
have used.

> I follow the example in the GSL document and set my success criteria as
> 
> status = gsl_multimin_test_gradient (s->gradient, 1e-20);

1e-20 is very very small, maybe to close to machine precision to give 
reliable results. But I'm far from being an expert in this domain. What 
look strange is that if the algorithm stops because of this criteria, I 
don't know why it can continue again after. It would mean that the norm 
of the gradient is going up after having reached 1e-20 once. This might 
be related to numerical errors.

> The initial setup of the vector is
> 
> T = gsl_multimin_fdfminimizer_conjugate_pr;
> s = gsl_multimin_fdfminimizer_alloc (T, 3*nparts);
> gsl_multimin_fdfminimizer_set (s, &energy, x, 0.001, 1e-12);

1e-12 is again quite small.

> For clarity, I used dimensionless units so ALL the nearest neighbor distances 
> and the coupling constants are of the order of unity. nparts is the number of 
> particles which is about 100000.
> 
> Could you give some advises? Thanks a lot in advance.
> 
> Toan

I think that you are basically puting the code under some pressure, 
because of the size of your problem and of the very low limits you are 
using. To my knowledge, it has not been tested under such constraints 
and it's therefore difficult to give sensible advice.

Fabrice


  reply	other threads:[~2004-12-15 11:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-11  7:44 Toan T Nguyen
2004-12-13 18:41 ` Linas Vepstas
2004-12-13 18:51 ` Fabrice Rossi
2004-12-14 23:03   ` Toan T Nguyen
2004-12-15 11:12     ` Fabrice Rossi [this message]
2004-12-15 12:11       ` Robert G. Brown
2004-12-15 17:31         ` Linas Vepstas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41C01C1A.8060306@apiacoa.org \
    --to=fabrice.rossi@apiacoa.org \
    --cc=gsl-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).