search

GalSim-developers / GalSim

The modular galaxy image simulation toolkit. Documentation:
http://galsim-developers.github.io/GalSim/
Other
223 stars 105 forks source link

Please fill in your build info on the new GalSim "Build Matrix" #130

Closed barnabytprowe closed 11 years ago

barnabytprowe commented 12 years ago

Hi all developers,

We've created a table of system info to help collate information about where and on what systems GalSim builds are succeeding or failing. This is to help try and diagnose larger patterns / solutions to issues such as #126, #128 and #74.

The table is currently on the GREAT3 Wiki pages, but we can move it to a public location if that is required:

http://great3.pbworks.com/w/page/53305390/Code%20Build%20Matrix

In addition, I've pushed a couple of changes (directly onto master as they are so small and harmless) that provide a way of getting at some of the deeper info regarding how your system stores integers and floats.

This is a short Python script in the devutils/ directory, called get_sysinfo.py. To use get_sysinfo.py you should first build scons examples, as this will compile the tiny sizeof_SIFD.cpp program needed to get the size of C++ short, int, float and double variables that get used by GalSim (admission: I couldn't get it building sensibly anywhere else due to my rawness at SConstruct...). Currently get_sysinfo.py (which should be run from within devutils) outputs this information along with the native byteorder. It should run from the command line as an executable, or via python get_sysinfo.py

Please do start filling in the matrix!

reikonakajima commented 12 years ago

Hello Barney,

I got the following error after "git pull", "scons -c" & similar, and then rebuilding with "scons", "scons install", "scons examples", "scons tests", and finally running:

reiko@violet.local~/2code/GalSim% devutils/get_sysinfo.py Native byteorder = little endian Traceback (most recent call last): File "devutils/get_sysinfo.py", line 7, in subprocess.check_call(['../bin/sizeof_SIFD']) File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/subprocess.py", line 506, in check_call retcode = call(_popenargs, _kwargs) File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/subprocess.py", line 493, in call return Popen(_popenargs, _kwargs).wait() File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/subprocess.py", line 679, in init errread, errwrite) File "/Library/Frameworks/EPD64.framework/Versions/7.2/lib/python2.7/subprocess.py", line 1228, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory

reikonakajima commented 12 years ago

Nevermind, I found out what the error is---I needed to be in the devutils directory to run the script.

reikonakajima commented 12 years ago

Hello again Barney,

The nosetests on one of my systems (Ubuntu, where I don't have sudo privileges) doesn't run at all. It runs fine on my MacBook. Here is the output:

scons tests TMV_DIR=/users/reiko/local/ PREFIX=/users/reiko/local/ PYPREFIX=/users/reiko/local/ scons: Reading SConscript files ... SCons is version 1.2.0.d20100117 using python version 2.6.5 Python is from /usr/include/python2.6 Using compiler: /usr/bin/g++ compiler version: 4.4.3 Determined that a good number of jobs = 64 Checking for C++ library cfitsio... (cached) yes Checking for C++ library fftw3... (cached) yes Checking for C++ header file boost/shared_ptr.hpp... (cached) yes Checking for C++ header file TMV.h... (cached) yes Using TMV_LINK file: /users/reiko/local/share/tmv/tmv-link -L/users/reiko/local/lib -ltmv -lcblas -lpthread -Wl,-rpath=/users/reiko/local/lib -fopenmp Checking for correct TMV linkage... (this may take a little while) Checking for correct TMV linkage... (cached) yes Checking if we can build against Python... (cached) yes Checking if we can build against NumPy... (cached) yes Checking if we can build against Boost.Python... (cached) yes Checking for PyFITS... (cached) yes scons: done reading SConscript files. scons: Building targets ... run_tests(["tests/tests.log"], ["bin/test_main"])

Starting python tests...

Ran 0 tests in 0.000s

OK Nosetests finished successfully.

Starting cpp tests... Running 3 test cases...

*\ No errors detected test_main finished successfully.

scons: done building targets.

barnabytprowe commented 12 years ago

Firstly, very sorry about that initial confusion Reiko, I've added the instruction to run get_sysinfo.py from within devutils to the GREAT3 Wiki page containing the build matrix. I'll also edit the original Issue message above.

Regarding the nosetests not running... Hmmm, I'm not sure what the problem could be. I noticed that the version of nosetests on your system is old (v0.11.1) but Joerg used that fine.

Would you be able to into the tests/ directory and simply type nosetests...? It should run from there, and will give us a clue if not...

reikonakajima commented 12 years ago

Hi Barney,

I was a bit too fast to ask help on get_sysinfo.py, sorry about that.

Would you be able to into the tests/ directory and simply type nosetests...?  It should run from there, and will give us a clue if not...

I did as you mentioned, and it gave the same error--no tests ran. (Sorry that I"m rather clueless, and thanks for your help!)

=-=-=-=-=-= tests > nosetests

Ran 0 tests in 0.000s

OK

barnabytprowe commented 12 years ago

I'll ask our resident nose expert, @joezuntz ... :) Have you seen anything like that before Joe? Could it be related to an old v0.11.1 version of nose? I'm going to look into it but wonder if you might have an idea.

In the meantime, I dug this up on stackoverflow and looks like a similar situation to your system Reiko: http://stackoverflow.com/questions/1457104/nose-unable-to-find-tests-in-ubuntu

Perhaps if you try the nosetests -vv --collect-only or nosetests -vv to get more info. Also, perhaps try running the test files individually, e.g. nosetests test_Image.py... The former two commands should give you more info, and the later one will be another clue if it works!

joezuntz commented 12 years ago

I have no extra insight beyond what Barney has just suggested, I'm afraid! Through using nosetests --version would tell us which version you are on.

rmandelb commented 12 years ago

According to the handy table that Barney made (http://great3.pbworks.com/w/page/53305390/Code%20Build%20Matrix) she's on 0.11.1, which is earlier than many of us, but Joerg uses that version without such issues.

On May 3, 2012, at 2:47 AM, joezuntz wrote:

I have no extra insight beyond what Barney has just suggested, I'm afraid! Through using nosetests --version would tell us which version you are on.

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5484224

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

rmjarvis commented 12 years ago

I added sizeof(long) to the sysinfo script. Recommend adding that to the table, since Joerg's problems came from sizeof(long) = sizeof(int).

Also, I'm interested in testing the code on a system with sizeof(int) = 8 (called 64 bits in Barney's code) if anyone has one of those.

rmandelb commented 12 years ago

Mike - I don't see that change on master, is it possible that they aren't pushed? I did add a column on the table for once that's in.

On May 3, 2012, at 6:20 AM, Mike Jarvis wrote:

I added sizeof(long) to the sysinfo script. Recommend adding that to the table, since Joerg's problems came from sizeof(long) = sizeof(int).

Also, I'm interested in testing the code on a system with sizeof(int) = 8 (called 64 bits in Barney's code) if anyone has one of those.

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5487279

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

rmandelb commented 12 years ago

Okay, I was being lazy, I just made that change myself and pushed it so it's available now.

rmandelb commented 12 years ago

@barnabytprowe , @reikonakajima , @TallJimbo , @joergdietrich , @HironaoMiyatake , @rmjarvis , can you please pull the updated script, run it, and fill in the column of the table for sizeof(long)? Thanks.

rmjarvis commented 12 years ago

Sorry, yes I forgot to push.

rmjarvis commented 12 years ago

Also, I don't think there exist any (modern) systems with float and double not equal to 32 and 64 bits, so those columns are probably unnecessary.

reikonakajima commented 12 years ago

Two things:

(1) I pulled the new version on my two systems, and everything (including the old-version nosetests on Ubuntu) runs fine. I will update the table accordingly.

(2) The earlier version (it was a tar download: GalSim-developers-GalSim-3c9763d) of nosetests, which I kept in the system for testing, still fails for the Ubuntu machine. The results for the diagnostic tests which Barney suggested are:

=-=-=-=-=

nosetests -vv --collect-only nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/SConscript is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/files.txt is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_Image.cpp is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_Image.py is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_SBProfile.py is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_SBProfile_comparison_images.x is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_artifacts.py is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_atmosphere.py is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_main.cpp is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_optics.py is executable; skipped nose.selector: INFO: /users/reiko/2code/GalSim-developers-GalSim-3c9763d/tests/test_random.py is executable; skipped

Ran 0 tests in 0.000s

OK =-=-=-=-=

Identical results for "nosetests -vv", but

=-=-=-=-=

nosetests test_Image.py

...............

Ran 15 tests in 0.095s

OK =-=-=-=-=

barnabytprowe commented 12 years ago

OK, so it is the same issue identified in the comments to the Stackoverflow issue above. Some installs of nosetests skip "executables"... The thing I'm confused about is why nosetests thought those test*.py files were exectuables at all, they should not be. Could be to do with the tarball clone I guess.

Just for closure, could you run ls -la on the contents of the directory in the offending version? Thanks Reiko!

barnabytprowe commented 12 years ago

(P.S. Mike: I don't think it hurts to keep the 32/64 bit float info, it's ~6 extra key presses to add them in, per person :) Thanks for including the long check though.)

reikonakajima commented 12 years ago

Hi Barney,

Yes, the filenames seems fine, so... Anyway, here is the ls -a output.

tests > nosetests

Ran 0 tests in 0.000s

OK

tests > ls -la total 200 drwxr-xr-x 5 reiko 4096 May 3 18:15 . drwxr-xr-x 14 reiko 4096 May 3 18:12 .. -rwxr-xr-x 1 reiko 229 May 3 01:55 ._.gitignore -rwxr-xr-x 1 reiko 229 May 3 01:55 ._Image_comparison_images -rwxr-xr-x 1 reiko 229 May 3 01:55 ._SBProfile_comparison_images -rwxr-xr-x 1 reiko 229 May 3 01:55 ._SConscript -rwxr-xr-x 1 reiko 229 May 3 01:55 ._init__.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._files.txt -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_Image.cpp -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_Image.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_SBProfile.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_SBProfile_comparison_images.x -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_artifacts.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_atmosphere.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_main.cpp -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_optics.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_random.py -rwxr-xr-x 1 reiko 10 May 3 01:55 .gitignore drwxr-xr-x 2 reiko 43 May 3 18:12 .obj drwxr-xr-x 2 reiko 150 May 3 04:04 Image_comparison_images drwxr-xr-x 2 reiko 4096 May 3 04:04 SBProfile_comparison_images -rwxr-xr-x 1 reiko 3556 May 3 01:55 SConscript -rwxr-xr-x 1 reiko 0 May 3 01:55 init__.py -rw-r--r-- 1 reiko 156 May 3 04:11 init.pyc -rwxr-xr-x 1 reiko 15 May 3 01:55 files.txt -rwxr-xr-x 1 reiko 936 May 3 01:55 test_Image.cpp -rwxr-xr-x 1 reiko 19309 May 3 01:55 test_Image.py -rw-r--r-- 1 reiko 14044 May 3 18:15 test_Image.pyc -rwxr-xr-x 1 reiko 24154 May 3 01:55 test_SBProfile.py -rwxr-xr-x 1 reiko 2485 May 3 01:55 test_SBProfile_comparison_images.x -rwxr-xr-x 1 reiko 44 May 3 01:55 test_artifacts.py -rwxr-xr-x 1 reiko 1655 May 3 01:55 test_atmosphere.py -rwxr-xr-x 1 reiko 474 May 3 01:55 test_main.cpp -rwxr-xr-x 1 reiko 13616 May 3 01:55 test_optics.py -rwxr-xr-x 1 reiko 8496 May 3 01:55 test_random.py -rw-r--r-- 1 reiko 146 May 3 18:12 tests.log

reikonakajima commented 12 years ago

I downloaded the most recent tarball version on my Ubuntu machine again (GalSim-developers-GalSim-20902e9), nosetest couldn't find the test_*.py files.

barnabytprowe commented 12 years ago

Yeah, they are all -rwxr-xr-x when they should normally be -rw-r--r--.

chmod 644 test*.py ought to fix it. Let me know!

On Thu, May 3, 2012 at 10:56 AM, Reiko Nakajima < reply@reply.github.com

wrote:

Hi Barney,

Yes, the filenames seems fine, so... Anyway, here is the ls -a output.

tests > nosetests

Ran 0 tests in 0.000s

OK

tests > ls -la total 200 drwxr-xr-x 5 reiko 4096 May 3 18:15 . drwxr-xr-x 14 reiko 4096 May 3 18:12 .. -rwxr-xr-x 1 reiko 229 May 3 01:55 ._.gitignore -rwxr-xr-x 1 reiko 229 May 3 01:55 ._Image_comparison_images -rwxr-xr-x 1 reiko 229 May 3 01:55 ._SBProfile_comparison_images -rwxr-xr-x 1 reiko 229 May 3 01:55 ._SConscript -rwxr-xr-x 1 reiko 229 May 3 01:55 ._init__.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._files.txt -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_Image.cpp -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_Image.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_SBProfile.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_SBProfile_comparison_images.x -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_artifacts.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_atmosphere.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_main.cpp -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_optics.py -rwxr-xr-x 1 reiko 229 May 3 01:55 ._test_random.py -rwxr-xr-x 1 reiko 10 May 3 01:55 .gitignore drwxr-xr-x 2 reiko 43 May 3 18:12 .obj drwxr-xr-x 2 reiko 150 May 3 04:04 Image_comparison_images drwxr-xr-x 2 reiko 4096 May 3 04:04 SBProfile_comparison_images -rwxr-xr-x 1 reiko 3556 May 3 01:55 SConscript -rwxr-xr-x 1 reiko 0 May 3 01:55 init__.py -rw-r--r-- 1 reiko 156 May 3 04:11 init.pyc -rwxr-xr-x 1 reiko 15 May 3 01:55 files.txt -rwxr-xr-x 1 reiko 936 May 3 01:55 test_Image.cpp -rwxr-xr-x 1 reiko 19309 May 3 01:55 test_Image.py -rw-r--r-- 1 reiko 14044 May 3 18:15 test_Image.pyc -rwxr-xr-x 1 reiko 24154 May 3 01:55 test_SBProfile.py -rwxr-xr-x 1 reiko 2485 May 3 01:55 test_SBProfile_comparison_images.x -rwxr-xr-x 1 reiko 44 May 3 01:55 test_artifacts.py -rwxr-xr-x 1 reiko 1655 May 3 01:55 test_atmosphere.py -rwxr-xr-x 1 reiko 474 May 3 01:55 test_main.cpp -rwxr-xr-x 1 reiko 13616 May 3 01:55 test_optics.py -rwxr-xr-x 1 reiko 8496 May 3 01:55 test_random.py -rw-r--r-- 1 reiko 146 May 3 18:12 tests.log

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5493813

Barnaby Rowe Postdoctoral Research Associate

Jet Propulsion Laboratory California Institute of Technology MS 169-237 4800 Oak Grove Drive Pasadena CA 91109 United States of America

Department of Physics & Astronomy University College London Gower Street London WC1E 6BT United Kingdom

reikonakajima commented 12 years ago

Yup, it now runs the nosetests. (Should have read the Stackoverflow article a bit more carefully.) Thanks!

joezuntz commented 12 years ago

It looks like there is also a flag for nosetests, --exe, which means executable files are also tested. We could enable that.

rmjarvis commented 12 years ago

That would be nice actually, since it would be convenient to make the individual .py files executable. I did this for Demo.py, so I can just type ./Demo.py rather than python Demo.py. The test scripts are useful to run singly while debugging, so I'd be in favor of doing the same for them so long as nosetests still works.

rmandelb commented 12 years ago

So... @rmjarvis , @TallJimbo , you have done much of the work on build-related issues, and especially diagnosing the system-dependent ones. Now that we have some info in this table, do you see any glaring gaps in the set of systems on which we can test the builds? Last week when I talked with Barney we thought that each of us might be able to find other places to try it, but we don't want to just randomly try it without a clear sense of what's missing.

@joezuntz , can you describe the system that the Jenkins test monitor runs on? That's a particularly useful one as it means we don't have to ping someone to go check it out, it gets done automatically. (Thanks again for that - I check it regularly!)

Likewise we might want to consider putting together a system to make sure that we regularly test on a fair subset of the systems on that table. I guess it could be a reminder on each pull request.

rmjarvis commented 12 years ago

The other places where I usually test my TMV code before a release, but which I haven't gotten galsim to work are mostly places where I have less control of the system configuration. I haven't put any of these into the build matrix yet, mostly because I haven't spent enough time trying to make them work to justify my claim that they don't work.

rmjarvis commented 12 years ago

Oh, and I don't check every pull request on all my systems. But I do try to run the gamut every so often. Mostly to pick up issues with the different compilers and such. Usually when I find something, I just fix whatever needs fixing. :)

TallJimbo commented 12 years ago

The thing that jumps out at me is that Joerg's "special" machine is our only 32-bit machine (and that's probably all that makes it special). If that is going away in the future, we'll really want to get another 32-bit machine or two.

We also don't have any clang/Linux boxes. That may not be that important, but it would be pretty easy to remedy since it's just a matter of installing another compiler.

rmjarvis commented 12 years ago

Oh, and there are a couple of computers that have older icpc's installed that I usually test against. Not sure how important that is.

rmandelb commented 12 years ago

We could e-mail the great3@ list to ask if anyone is working on a 32-bit machine and would be willing to help us out once Joerg loses access to his. Although I just realized that there are a few 32-bit machines in the Princeton astro dept that both Jim and I should in principle have access to. However, I'm not sure how easy it would be to install these packages etc. - we don't have much control over those systems.

Mike, I agree that you don't have to test on all your machines for each pull request... once in a while is good enough. (Assumign that means ~once every few weeks, so we can keep up with the rapid changes in the code.)

Jim, perhaps I should consider installing clang on my linux box in the astro dept? (I've been lazy so far, only installing the code on my Mac. So really I'd have to install clang + various packages.) Or, is it installed on one of the machines that is sometimes used for HSC/LSST processing? I don't see it on sesame3 but I could check on hsca unless you know offhand.

TallJimbo commented 12 years ago

I could probably get a build going on a 32-bit machine in the department pretty easily by using the LSST versions of everything but the compiler. Do you have one in mind?

There's no clang on hsca either, but I believe Mario Juric has an LSST system at Arizona I could get access to with Clang+Linux, so that would be a possibility. I've also been meaning to set it up on my own system, but it hasn't been a high priority.

rmandelb commented 12 years ago

32-bit machines in the dept: I just remember seeing some on the list of machines in the condor pool... looks like apache2, apache3, coma, photo4, photo7, photo8. I have to check, though, as at least some of those might be going away soon, and it's not worth spending time installing if that's the case.

As for clang, it sounds like either of those options (Mario's machine or yours) would involve some non-negligible work, so perhaps we could see if someone else has it as an option on their machine already?

barnabytprowe commented 12 years ago

Aha, I've located some 32-bit machines at Caltech that I have access to, I'll build there.

rmandelb commented 12 years ago

Will you have access to those once you're done at JPL in late July? If not, then perhaps the machines at Princeton are a better bet (I will have an account with at least some access indefinitely after I leave, and Jim has a few years here).

On May 8, 2012, at 11:34 AM, Barnaby Rowe wrote:

Aha, I've located some 32-bit machines at Caltech that I have access to, I'll build there.

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577578

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

barnabytprowe commented 12 years ago

Yes, I believe my caltech.astro account access is now indefinite! (JPL definitely not, but Caltech is a far more humane institution ;)

On 8 May 2012, at 08:42, Rachel Mandelbaum wrote:

Will you have access to those once you're done at JPL in late July? If not, then perhaps the machines at Princeton are a better bet (I will have an account with at least some access indefinitely after I leave, and Jim has a few years here).

On May 8, 2012, at 11:34 AM, Barnaby Rowe wrote:

Aha, I've located some 32-bit machines at Caltech that I have access to, I'll build there.

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577578

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577808

Barnaby Rowe

Jet Propulsion Laboratory California Institute of Technology MS 169-237 4800 Oak Grove Drive Pasadena CA 91109 United States of America

Department of Physics & Astronomy University College London Gower Street London WC1E 6BT United Kingdom

rmandelb commented 12 years ago

Okay, so the JPL account will still close 3.7 nanoseconds after you leave. Got it.

As for Caltech: how annoying would be for you to install the dependencies and build there? If it's going to be an enormous pain, then we should compare the relative difficulty vs. at Princeton (where there will be some pain but probably not too much).

On May 8, 2012, at 11:45 AM, Barnaby Rowe wrote:

Yes, I believe my caltech.astro account access is now indefinite! (JPL definitely not, but Caltech is a far more humane institution ;)

On 8 May 2012, at 08:42, Rachel Mandelbaum wrote:

Will you have access to those once you're done at JPL in late July? If not, then perhaps the machines at Princeton are a better bet (I will have an account with at least some access indefinitely after I leave, and Jim has a few years here).

On May 8, 2012, at 11:34 AM, Barnaby Rowe wrote:

Aha, I've located some 32-bit machines at Caltech that I have access to, I'll build there.

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577578

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577808

Barnaby Rowe

Jet Propulsion Laboratory California Institute of Technology MS 169-237 4800 Oak Grove Drive Pasadena CA 91109 United States of America

Department of Physics & Astronomy University College London Gower Street London WC1E 6BT United Kingdom

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-5577881

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

barnabytprowe commented 12 years ago

I'm just taking a quick look now. I'm not sure they have boost, but that shouldn't be too bad. And the computing support here is very good, generally. It wouldn't hurt to have both here and Princeton!

rmandelb commented 12 years ago

Yeah, if it's just boost then that's not such a big deal. (You already know this, but for the others in the conversation -) I decided to shelve looking into machines in Princeton until after the milestone. We can just leave the issue open; in any case, there are other things to resolve in it as well (e.g., clang).

rmjarvis commented 12 years ago

This issue seems a bit stale. Suggest we close it unless there is more to do in terms of putting some direction to developers to add to their system to the build matrix somewhere in our credo or other docs.

rmandelb commented 12 years ago

I think we should (a) put something about this in the documentation (perhaps credo and INSTALL, to be thorough), and (b) decide if there are any systems we don't have that we'd like to have. For example, we discussed 32-bit machines and I don't think anything happened there, or if it did, I missed it. I assume this is still something we want - could open a separate issue for it, and to decide if there are any other systems we'd like to regularly test on.

barnabytprowe commented 12 years ago

I personally still owe either this Issue or a very closely-related one a couple of builds on Linux machines at Caltech, and apologise that this has taken so long. I propose that I'll assign it to myself to do this, and to add some text to credo and INSTALL, then we can see about closing the Issue... Sound OK?

rmandelb commented 12 years ago

Fine with me.

On Jun 18, 2012, at 2:53 PM, Barnaby Rowe wrote:

I personally still owe either this Issue or a very closely-related one a couple of builds on Linux machines at Caltech, and apologise that this has taken so long. I propose that I'll assign it to myself to do this, and to add some text to credo and INSTALL, then we can see about closing the Issue... Sound OK?

Reply to this email directly or view it on GitHub: https://github.com/GalSim-developers/GalSim/issues/130#issuecomment-6405483

Rachel Mandelbaum http://www.astro.princeton.edu/~rmandelb rmandelb@astro.princeton.edu

rmjarvis commented 12 years ago

I added a link to the build matrix page from the front page of our wiki. So the url is easily accessible from other than this issue.

rmandelb commented 11 years ago

Hello everyone in the build matrix ( @barnabytprowe @reikonakajima @rmjarvis @msimet @TallJimbo @joergdietrich @HironaoMiyatake @joezuntz ): as you may have seen, Melanie (@msimet) recently opened an issue that had to do with her version of numpy. She pointed out that the build matrix didn't have a column for numpy, so she added one since it seems that might be useful to have. Can you please add that information at your leisure?

barnabytprowe commented 11 years ago

Aha yes, good point. Will do!

barnabytprowe commented 11 years ago

For info, the easiest way to do this is probably in your python interpreter. For example:

>>> import numpy
>>> numpy.version.version
'1.6.1'
barnabytprowe commented 11 years ago

Rachel and I decided to close (for closure) as we have a good set of systems now. Thanks all!