Menu
▾
▴
hola-hackers — Developers for the Hola Project
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(24) |
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <ben...@id...> - 2004-05-22 12:26:06
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Philip F. K. <fl...@mr...> - 2003-04-30 20:44:59
|
To fix an overflow (and a bad idiom), I added a global constant MAX_FILENAME_LEN; replaced instances of string[50] and the like with the more descriptive filename[MAX_FILENAME_LEN] or string[MAX_FILENAME_LEN] as appropriate. This hit many files so you may want to cvs up. flip |
|
From: Philip F. K. <fl...@mr...> - 2003-04-30 09:44:45
|
I cvs comitt'ed some changes. Nothing earthshaking.
src/measure/reports.c
src/cfg/readin_params.c
Greatly improved mathematica export routines
src/py/msspd_swig.c
Added accessors for PE, KE to python shadow object.
Also ameliorated (but didn't solve) python crashes by
using n_dynm_part instead of n_part.
potential/lj_hack.c
potential/sw.c
deform/defedge.c
verlet.c
Added code for the SU_hack simulations to freeze one type of atom.
Also added conditional to run single-atom force test.
make_space.c
Babbles more after reading initial configuration from file
Makefile-cygwin
While helping Jon with something I discovered a couple more optimization
flags to try out.
flip
|
|
From: Philip F. K. <fl...@mr...> - 2003-04-25 06:05:54
|
Is it OK to move find_exc_cutoff (currently in exchange) and setup_cutoff (in setup_misc) to a new file potential/cutoff.c? flip |
|
From: Philip F. K. <fl...@mr...> - 2003-04-22 22:18:19
|
verlet.c was ignoring freeze_dy -- I fixed so that CT_freeze_dy is respected now: if set to 0 free boundaries apply, as before; if set to non-zero (even negative) sticky boundaries apply. (same as for freeze_dx and freeze_dz). I've added a hybrid potential, with flag SU_hack, that applies one potential to atoms of the same type and a different potential to atoms of different type. sw.c was modified so that it only acts on atoms of the same type (which should be harmless as it is a silicon-only potential). I fixed all the compiler warnings that were easy to fix. One change of note is that the index 'jn' and its friends 'jn_init' and 'jn_max' have been renamed nbr, nbr_init, etc.; kn, kn_init, kn_max are now nextnbr, nextnbr_init, nextnbr_max. flip |
|
From: Philip F. K. <fl...@mr...> - 2003-04-21 11:25:23
|
--- Matthew Lane <ml...@ch...> wrote: > Your most recent mod to Makefile-aix causes a linker error on Longhorn. > I am using v1.8 without any problem, 1.9 creates the problem. The IBM Compiler, i discovered, doesn't like it if you use -qipa and -qextchk at the same time. I can't tell why that is, so for now I made the default, CFLAGS_OPT_CRAZY, have -qnoipa; and I added CFLAGS_OPT_NUTSO, with -qipa turned on. If you use that choice, de-select -qextchk in CFLAGS_LINT. It seems that -qipa drastically increases compile time, with uncertain runtime benefits. (ipa means "interprocedural analysis;" see http://www.cs.utk.edu/~dongarra/WEB-PAGES/perf_opt1/tsld076.htm http://www.cascv.brown.edu/compute/cxxmanual/complink/ref/ruoptipa.htm ) Tell me if you notice any improvement between -qipa and -qnoipa. I also took another tour through the xlc manpage and changed settings for -qfloat= fold evaluate constant float expressions at compile time fltint speed up conversions by not checking overflow hssngl suppress rounding to improve performance hsflt suppress all rounding and convert from float to int with inline code; more dangerous than hssngl -qflttrap -- adds extra code to trap floating-point exceptions -qinitauto=XX -- adds extra code to initialize storage to hex value "XX". -qheapdebug -- use debug_malloc, etc; also preinitialize locals If you want to be brave uncomment parts of CFLAGS_CHECK to enable various error-checking instrumentation. flip |
|
From: Philip F. K. <fli...@ya...> - 2003-04-08 20:46:47
|
here is the description of the changes: http://sourceforge.net/mailarchive/forum.php?thread_id=1816039&forum_id=31802 flip --- Matthew Lane <ml...@ch...> wrote: > Could you write a detailed summary of the changes that you've made to > the procedure structure. I know we talked about these and agreed on > them, but it's been a while. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com |
|
From: Matthew L. <ml...@ch...> - 2003-04-08 19:12:57
|
I just held my breath and did a cvs update for the first time in a few weeks. I was brave. Now I can't compile. make: *** No rule to make target `finish.c', needed by `Objs/finish.o'. Stop. Am I doing something silly? Flip did you eliminate this procedure from the code, but leave it in the makefile? I have up to date makefiles. Could you write a detailed summary of the changes that you've made to the procedure structure. I know we talked about these and agreed on them, but it's been a while. Thanks, Matt |
|
From: Matthew L. <ml...@ph...> - 2003-04-07 17:38:33
|
I just held my breath and did a cvs update for the first time in a few weeks. I was brave. Now I can't compile. make: *** No rule to make target `finish.c', needed by `Objs/finish.o'. Stop. Am I doing something silly? Flip did you eliminate this procedure from the code, but leave it in the makefile? I have up to date makefiles. Could you write a detailed summary of the changes that you've made to the procedure structure. I know we talked about these and agreed on them, but it's been a while. Thanks, Matt |
|
From: Philip F. K. <fl...@mr...> - 2003-03-27 22:20:19
|
I've finally found a good python plotting package: Biggles: "Better living through plotting" http://biggles.sourceforge.net/ it's simple, works well, and has few dependencies (only Numeric and Gnu plotutils). It has a python OO interface and also a matlab-plot-syntax layer; see example9.py in the source distribution. I'm using it to add a window that will display the simulation variables (energy, pressure, strain, distance something's been dragged, whatever) as the simulation progresses. yours in devious plotting, flip |
|
From: Philip F. K. <fl...@mr...> - 2003-03-11 08:44:46
|
Minor change hitting many files. We used to set a variable named 'root', initialize it to 0, and use that as the constant indicating root; now we refer to a constant #define ROOT_NODE 0 that was added to parallel.h old: ... int root=0; ... ... MPI_Bcast( &prev_tip_xloc, 1, MPI_DOUBLE, root, comm_3D ); ... new: ... ... MPI_Bcast( &prev_tip_xloc, 1, MPI_DOUBLE, ROOT_NODE, comm_3D ); ... flip |
|
From: Philip F. K. <fl...@mr...> - 2003-03-11 08:38:21
|
I've made some changes to the code flow -- thing work the same, they're just
called from slightly different places.
The structure of the code used to be
main
+--- MPI_setup
|
+--- readin_params
+--- setup_cutoff
+--- make_space
|
+--- phys_params
+--- make_crystal or readin_confg
+--- setup_misc
|
+--+ do_physics
|
+--- cut
+--- unit_dims
+--- strain
+--- seed
|
+--+ dynamics
|
+--- dynm_init
+--+ dynm_crack
|
+--+ while (steps) do
+--- ( ... stuff ... )
+--+ until done
|
+--+ finish
|
+--- final_record
+--- free_up
+--- finalize_MPI
For design reasons, and for convenience in the C-to-python scripting
transition, we have flattened this tree somewhat.
main
+--- MPI_setup
|
+--- readin_params
+--- setup_cutoff
+--- make_space
|
+--- phys_params
+--- make_crystal or readin_confg
+--- setup_misc
|
+--+ do_physics
|
+--- cut
+--- unit_dims
+--- strain
+--- seed
+--- dynm_init
|
+--+ while (steps) do
+--- dyn_step
+--+ until done
+--+
|
+--- final_record
+--- free_up
+--- finalize_MPI
Now things that fall under "Set up / Take down the computational arena" are
set in place by main(); things that fall under "Make physics happen" are in
do_physics().
The following changes were incurred:
OLD NEW
dynamics -gone- Its code is now in do_physics.
dynm_init dyn_init left alone, except for name change --
but will be reworked soon.
dynm_crack dyn_step Does a single step, not a whole loop.
do_physics do_physics now has the while loop; it calls dyn_init()
and then loops on calls to dyn_step()
finish.c -gone- its code is in main.c
dynm_squ_str dyn_squ_str Moving this to the deform/ directory,
and renaming it dyn_ (not dynm_) to match.
What is the difference between dyn_squ_str and
squ_str?
I also want to ask about these files that are not in the current Makefile.
Are they pertinent? If not they should go to _other with rest of dead code.
nrg_force3.c -exiled- what's this do?
multi_verlet.c -exiled- What's different btwn verlet and multi_verlet?
exc_[xz]_* -nuttn yet-
meam.test.c -nuttn yet-
The renamed routines are still in the old-named files; we don't want to lose
the cvs repository info. The changes I've requested are as follows:
RENAME dynm_squ_str.c TO deform/dyn_squ_str.c
RENAME dynm_crack.c TO dyn_step.c
RENAME dynm_init.c TO dyn_init.c
I (will) have asked the sf.net admins to rename these files within the
repository; once they do the move, the next person who cvs update's will
have a broken Makefile. If this is you, simply rename the files in your
Makefile, verify that it works again, and commit the Makefile.
dyn'amically yours,
flip
|
|
From: Philip F. K. <fli...@ya...> - 2003-03-09 20:55:53
|
Hmmm... can't reproduce this on linux. This may be a cygwin MPI bug. Never mind for now, I guess. flip --- Philip Flip Kromer <fl...@mr...> wrote: > > exchange dies in swap_ghost_send for more than 850 face particles; I > don't know enough about MPI to fathom why this is so. To see this, use > the run in examples/trihooke with LWH (53.49,6.99,3.464) or > examples/tin_shock with (130.23,5.92,32.32) __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Michael M. <ma...@ch...> - 2003-03-09 03:38:17
|
Since fg is not a silicon potential, the recital below doesn't sound so bad. You might be seeing surface reconstruction. Philip Flip Kromer wrote: >I simultaneously changed the lattice constants CR_a,b,c and prim axes >A1x,A2y,A3z to 5.4305 (the normative value), to 5.8305 and to 6.4305. > > - sw at 5.4305 is extremely stable. Given an expanded crystal it > valiantly tries to return to its smaller crystal value. > > - fg expands without seeming limit even up to lattice const. of 7.4 > > - At 5.4305 EDIP is actually stable, but has a very high vapor pressure: > > the edges of the crystal get very mushy but the bulk stays mostly > fixed. At higher values it does contract but is even meltier. > > - SW-Rose rejects its boundary particles and shrinks its bulk (an > extreme version of above). The melting quickly extends several layers > into the crystal > >flip > >--- Michael Marder <ma...@ch...> wrote: > > >>Do these potentials assume the same equilibrium lattice constants as >>sw? >>Would small differences in the value of a account for the expansion? Is >> >>the expansion violent or mild? >> >>Philip Flip Kromer wrote: >> >> >> >>>I set up a stability run in examples/fg with no periodic boundaries >>> >>> >>(so >> >> >>>there is no danger of compression from setting the system size wrong). >>> >>>Each of fg, edip, and rose fail the stability test -- the crystal >>> >>> >>starts >> >> >>>growing and melting. >>> >>>Any ideas? >>> >>>flip >>> >>> >>> >>> > > >__________________________________________________ >Do you Yahoo!? >Yahoo! Tax Center - forms, calculators, tips, more >http://taxes.yahoo.com/ > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Hola-hackers mailing list >Hol...@li... >https://lists.sourceforge.net/lists/listinfo/hola-hackers > > > |
|
From: Matthew L. <ml...@ch...> - 2003-03-09 00:39:59
|
I tried the digest option, but it makes it very hard to reply to individual messages. So, I'm back to getting everything in realtime. If the traffic keeps up like this, I'd suggest we migrate to a forum/discussion board. My inbox can't handle another 8-10 messages a day. I'd like a way to browse all the messages and comments, then reply to each individually if necessary. Digest won't do that. Even when I go to the archive on sourceforge, there is no reply option! The threads are all there - real nice, but no way to contribute via the web interface. Flip, have you ever used the forum option on sourceforge? Would it resolve this? Matt |
|
From: Matthew L. <ml...@ch...> - 2003-03-08 23:38:51
|
Sent this from the wrong address and it bounced...
-------- Original Message --------
Subject: rose, edip, and fg are all unstable
Date: Sat, 08 Mar 2003 16:35:58 -0600
From: Matt Lane <ma...@la...>
To: hol...@li...
the edges of the crystal get very mushy but the bulk stays mostly
fixed. At higher values it does contract but is even meltier.
You're going to get surface reconstruction on all of the potentials.
Free boundaries will always relax. These relaxations may or may not be
valid reconstructions. But, they aren't unphysical, most if not all
crystals have a boundary layer of distorted crystal at the surface.
The lattice constants will not match experiment in general, you'll need
to find a paper on each potential and match to the constants that they
publish. Or, go through the process of finding your own which can be
delicate in a multidimensional space!
Matt
|
|
From: Matthew L. <ml...@ch...> - 2003-03-08 22:30:15
|
FG stands for Feuston-Garofalini which is a potential designed to similate silica. If you're trying to put it in a silicon crystal structure it will always blow up. I've never used Rose_sw or EDIP, but I would imagine that they are stable under the proper configurations. Simply because they were when last used by Dominic. YOu can confirm that with Dominic. If it were me, I'd try to fiddle with em a little, before announcing they are unstable. Each potential is unique in small ways. You'll need to pull up a paper or two and get some dirt under your nails for each I'd expect. Matt |
|
From: Philip F. K. <fl...@mr...> - 2003-03-08 20:12:21
|
exchange dies in swap_ghost_send for more than 850 face particles; I don't know enough about MPI to fathom why this is so. To see this, use the run in examples/trihooke with LWH (53.49,6.99,3.464) or examples/tin_shock with (130.23,5.92,32.32) flip |
|
From: Philip F. K. <fli...@ya...> - 2003-03-08 19:54:05
|
I simultaneously changed the lattice constants CR_a,b,c and prim axes A1x,A2y,A3z to 5.4305 (the normative value), to 5.8305 and to 6.4305. - sw at 5.4305 is extremely stable. Given an expanded crystal it valiantly tries to return to its smaller crystal value. - fg expands without seeming limit even up to lattice const. of 7.4 - At 5.4305 EDIP is actually stable, but has a very high vapor pressure: the edges of the crystal get very mushy but the bulk stays mostly fixed. At higher values it does contract but is even meltier. - SW-Rose rejects its boundary particles and shrinks its bulk (an extreme version of above). The melting quickly extends several layers into the crystal flip --- Michael Marder <ma...@ch...> wrote: > Do these potentials assume the same equilibrium lattice constants as > sw? > Would small differences in the value of a account for the expansion? Is > > the expansion violent or mild? > > Philip Flip Kromer wrote: > > >I set up a stability run in examples/fg with no periodic boundaries > (so > >there is no danger of compression from setting the system size wrong). > > > >Each of fg, edip, and rose fail the stability test -- the crystal > starts > >growing and melting. > > > >Any ideas? > > > >flip > > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ |
|
From: Michael M. <ma...@ch...> - 2003-03-08 16:38:23
|
Do these potentials assume the same equilibrium lattice constants as sw? Would small differences in the value of a account for the expansion? Is the expansion violent or mild? Philip Flip Kromer wrote: >I set up a stability run in examples/fg with no periodic boundaries (so >there is no danger of compression from setting the system size wrong). > >Each of fg, edip, and rose fail the stability test -- the crystal starts >growing and melting. > >Any ideas? > >flip > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger >for complex code. Debugging C/C++ programs can leave you feeling lost and >disoriented. TotalView can help you find your way. Available on major UNIX >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Hola-hackers mailing list >Hol...@li... >https://lists.sourceforge.net/lists/listinfo/hola-hackers > > > |
|
From: Philip F. K. <fl...@mr...> - 2003-03-08 06:05:24
|
I set up a stability run in examples/fg with no periodic boundaries (so there is no danger of compression from setting the system size wrong). Each of fg, edip, and rose fail the stability test -- the crystal starts growing and melting. Any ideas? flip |
|
From: Matthew L. <ml...@ch...> - 2003-03-08 04:46:57
|
I don't believe that exchange and the ghosting mechanisms have ever worked in situations in which communication would be required beyond immediate nodal neighbors. Mike, correct me if I'm wrong on that. I'm not sure whether we want to plan for it or not. We might just enforce that "short-range" potentials mean that the cutoff will always be smaller than the nodal extent. You can imagine that allowing for "long-range" cutoffs beyond the nodal dimension will result in strange problems like having 26 times more ghost particles than dynamic particles! This is inherently problematic from a memory perspective. Or, for periodic boundary conditions, self-forces. I'd suggest putting realistic limitations on cutoffs and working to develop alternatives for "long-range" potentials other than ghosting. I personally don't know much about these methods, but Vashista, etc. use multipole methods. Ewald methods might also be tools we should add to the toolkit. The short answer is, for now, don't do this... :^) Matt Philip Flip Kromer wrote: >Exchange sits&spins when the cutoff is greater than the system in some >dimension. I don't think it's an urgent issue, but I do think it's a >reasonable case the code should handle. > >flip > |
|
From: Matt L. <ml...@ch...> - 2003-03-08 04:44:08
|
I'm removing these two from the CVS, because they are both now accomplished by swap.c Matt |
|
From: Matt L. <ml...@ch...> - 2003-03-08 04:44:03
|
Hi Flip, I managed to ci a few files today. This CVS stuff ain't so bad. I thought I'd let you know that I made mods to nrg_force_init and Makefile - both minor cleanups. I also added a procedure called piston.c for implementing shocks. Readin_config and dynm_crack were changed only to add two new variables and call piston. If the DY_shock param is missing or 0, everything should run exactly as before. BUG: (well annoyance at least) The babble routine writes for every node. I'm running on two currently and the processors are overwriting each other in a garble (not babble). An if (par->me == 0) statement might be the best way to handle that... Matt And, yes, I owe you some examples... |
|
From: Matt L. <ml...@ch...> - 2003-03-08 04:43:59
|
I concur with the honorable Flip's assessment of risk, but would like to see a UN resolution on the subject before action is taken. I proposed a new cabinet level position of homedirectories security, and nominate Flip to serve the new post. Recent intercepted communications from our highest intelligent sources: COL: Captain Ibrahim? CAPT: I am with you, Sir. COL: Remove. CAPT: Remove. [Repeats instructions] COL: The braces. CAPT: The braces. COL: "around conditionals and for loops." CAPT: around conditionals and loops. COL: _for_ loops. CAPT: for loops, yes, I have it. END COMMUNICATION That is all, Matt |
