l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Nov 19 13:00

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Assistance With C Program - Abit of Physics Here
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Assistance With C Program - Abit of Physics Here

Thanks for the suggestions, I will look into them.

But unfortunately for this algorithm I need to have dynamic allocation to 
maintain somewhat of a manageable program size.  The problem is thus:

I have no idea how many energy levels are possible for a system.  I know 
the max and the min however and I know the step size between the max and 
min.  However this number is on the order of 10^6 for small lattices (8x8) 
and grows very fast (exponetially) on larger lattices (Highly dependant on 
lattice size and constants that one is using).  Out of the total number of 
levels, only about 1.0-0.01% are visited and they are not visited 
regularly and the levels change whenever you change any part of the 
system.  So I allocate an array of pointers for every level and then when 
I come across one of the possible levels, I allocate the space for all the 
information that I need about that level (user defined structure).

I have choosen this method because I do not want to use a mesh because do 
not want to group energy levels together. I would like to see exactly the 
probability of being at that energy level (This is the essence of the Wang-
Landau Algorithm that is being implemented here).

I hope that makes since.

Dan Hurt

> hi dan,
> On Tue 18 Nov 03,  4:40 PM, Daniel Hurt <dwhurt@ucdavis.edu> said:
> > 
> > Specifically:  Finding possible memory leaks and when it is 
appropriate to 
> > use the free() functions. Next, I am not too terribly sure on how to 
use a 
> > debugger to track down the leak.  Finally, just discussing programming 
> > style with someone who knows C to look at it and critique the code.  
> > code itself works, it just takes an exceedingly long time and every so 
> > often I am running into problems with the size of the program.  I do 
> > need help with the physics behind what is going on because the code 
> > actually generates good results. I am just trying to analyze larger 
> > systems that should be well within the limits and encountering 
> if i can guess at what your research is, you don't need to use dynamic
> memory for your spin lattice if you use c99.  you can declare arrays
> with non-constants, so you can do something like this:
> ./montecarlo --latticesize=50
> and you don't need to allocate the array dynamically.
> but to answer your question, it's always appropriate to use free()
> whenever you use malloc() and friends (except for dynamic memory
> allocated from the stack, like alloca()).  if you don't, the memory is
> unavailable for the duration of your application, but will be returned
> when your program exits.  if you're doing monte carlo on small lattices,
> a memory leak is really not a big deal since you only allocate the array
> once.  it's just unaesthetic.
> to answer your question about how to find memory leaks: there's lots and
> lots and lots of ways.  some easy, and some hard.  look at
>    info libc
> and do a search on MALLOC_CHECK.  you'll be taken to a node that has a
> few ways to catch dynamic memory problems.  the simplest method is the
> MALLOC_CHECK_ method itself (note the terminating underscore).
> basically, you'll want to set an environment variable named
> MALLOC_CHECK_ to a 0 (to ignore problems), a 1 (to warn about problems)
> or a 2 (to dump core when a problem is encountered) or a 3 (to both warn
> and dump core when a problem is encountered).
> note that "3" is undocumented.   you can invoke it like so:
>    $ MALLOC_CHECK_=3 ./myprogram
> i can give you further guidance if you need it.
> there are meny other ways.  see "man efence" for example.  electric
> fence is another tool to debug dyanmic memory problems.  each tool has
> its strengths and weaknesses.  
> for instance, MALLOC_CHECK_ doesn't work with the concept of
> "boundaries" while electric fence does.  this means that efence can
> catch certain problems that MALLOC_CHECK_ can't.  for instance, i
> believe pure memory leaks will not be detected by MALLOC_CHECK_, while
> things like double frees and writing to freed memory will.
> hth,
> pete
> -- 
> GPG Instructions: http://www.dirac.org/linux/gpg
> GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
EDGE Tech Corp.
For donating some give-aways for our meetings.