<div dir="ltr">Hi Richard,<div><br></div><div>At the moment, buildbot for dials runs these three tests:</div><div>libtbx.import_all_ext<br></div><div>cctbx_regression.test_nightly<br></div><div>libtbx.run_tests_parallel module=dials nproc=auto verbosity=1<br></div><div><br></div><div>Which doesn't line up exactly with what you described. If you run <span style="font-size:12.8000001907349px">libtbx.run_tests_parallel module=cctbx module=dxtbx, then you are right that the fix I committed wouldn't be relevant because mmtbx wouldn't be tested. However, since the LBL build bot runs cctbx_regression.test_nightly, my change is needed.</span></div><div><br></div><div>After some more discussion, I see that Markus's changes to tst_geometry_restraints_2.py are fine. It looks like there are already sub-tests in there that check for the presence of mmtbx and chem data before running. I think tst_geometry_restraints_2.py was the only test outside of mmtbx that was looking for the monomer libraries.</div><div><br></div><div>I'm re-running the buildbot dials build now to see if my change to cctbx_regression.test_nightly along with Markus's changes to tst_geometry_restraints_2.py clean up the build.</div><div><br></div><div>Finally, and perhaps on a different note, should we add dxtbx to cctbx_regression.test_nightly? Right now the list of modules it tests includes libtbx, boost_adaptbx, scitbx, cctbx, iotbx, smtbx, and if chem_data is present, mmtbx. I don't think the build bot is running the dxtbx tests at present.</div><div><br></div><div><span style="font-size:12.8000001907349px">-Aaron</span></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 1:36 PM, <span dir="ltr"><<a href="mailto:richard.gildea@diamond.ac.uk" target="_blank">richard.gildea@diamond.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Aaron,<br>
<br>
I'm not sure your fix as I understand it actually helps. The test that was failing was in the cctbx module, not mmtbx, and as far as I am aware we are running libtbx.run_tests_parallel module=cctbx module=dxtbx etc in our nightly builds (and that is what we as developers are running locally on our own development machines). If individual tests (particularly those in the more general modules such as cctbx, iotbx, etc.) rely on external dependencies (such as chem_data) being available, then the individual tests should test for presence of said dependencies and skip gracefully if not available. I have a feeling that we're not even including mmtbx in our nightly build tests (too many fail due to missing dependencies such as chem_data).<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
________________________________<br>
From: Aaron Brewster [<a href="mailto:asbrewster@lbl.gov">asbrewster@lbl.gov</a>]<br>
Sent: 07 April 2015 20:29<br>
To: cctbx mailing list<br>
Cc: Waterman, David (STFC,RAL,SC); Gildea, Richard (DLSLtd,RAL,LSCI); Johan Hattne; <<a href="mailto:dials-support@lists.sourceforge.net">dials-support@lists.sourceforge.net</a>><br>
Subject: Re: [cctbxbb] [Dials-support] DIALS source tarball<br>
<span class=""><br>
Hi Markus, two points.<br>
<br>
First, you are correct that the dials builds are not passing tests related to the chem_data folder which includes monomer libraries. This is because chem_data is required by mmtbx but isn't included in the dials build. Partly because we're unsure if pieces of it are proprietary. In the meantime, I've worked with Nigel to change the cctbx_regression.test_nightly to look for the chem_data repository and skip the mmtbx tests if it's not present. mmtbx will still be tested nightly as part of the standalone cctbx and phenix packages. Because of this change, perhaps you could revert your recent changes to cctbx/regression/tst_geometry_restraints_2.py? It isn't necessary to check for chem_data in every sub test as it is tested for at the top level now.<br>
<br>
Second, the log you provided is not the one on buildbot. Your log indicates you have a CCP4 installation that includes a monomer library that is being picked up by the tests. Is one of the MMTBX_CCP4_MONOMER_LIB, or CLIBD_MON environment variables set on the system in question?<br>
<br>
Thanks,<br>
-Aaron<br>
<br>
<br>
<br>
</span><span class="">On Tue, Apr 7, 2015 at 6:41 AM, <<a href="mailto:markus.gerstel@diamond.ac.uk">markus.gerstel@diamond.ac.uk</a><mailto:<a href="mailto:markus.gerstel@diamond.ac.uk">markus.gerstel@diamond.ac.uk</a>>> wrote:<br>
Cc'ing cctbx folks<br>
<br>
David Waterman wrote:<br>
</span>> So maybe once we have a source tarball up at <a href="http://dials.diamond.ac.uk" target="_blank">dials.diamond.ac.uk</a><<a href="http://dials.diamond.ac.uk" target="_blank">http://dials.diamond.ac.uk</a>> (..)<br>
<div><div class="h5"><br>
Speaking of which: our DIALS builds are currently failing at the installer testing stage. This is due to cctbx/regression/tst_geometry_restraints_2.py failing deep in mmtbx territory.<br>
So far I could not figure out how to get this running properly.<br>
<br>
<br>
Call:<br>
<br>
libtbx.python tst_geometry_restraints_2.py<br>
<br>
Standard Output<br>
<br>
Skipping exercise_with_zeolite(): input file not available<br>
Skipping exercise_with_pdb(): chem_data directory not available<br>
<br>
Standard Error<br>
<br>
Traceback (most recent call last):<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 866, in <module><br>
exercise_all(sys.argv[1:])<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 862, in exercise_all<br>
exercise_na_restraints_output_to_geo(verbose=verbose)<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 805, in exercise_na_restraints_output_to_geo<br>
log=out1)<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 5270, in run<br>
log=log)<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 4876, in __init__<br>
restraints_loading_flags=restraints_loading_flags,<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2902, in __init__<br>
log=log,<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2287, in __init__<br>
m_j=mm)<br>
File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 1513, in get_lib_link<br>
return mon_lib_srv.link_link_id_dict["rna3p"]<br>
KeyError: 'rna3p'<br>
<br>
<br>
(On a side note: We really should call multiple tests within the same python file separately, instead of running them together within a signle run() method. This file contains 4 tests, but these will result in only a single return value for any upstream processing of the test results, such as Jenkins.)<br>
<br>
-Markus<br>
<br>
--<br>
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.<br>
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.<br>
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.<br>
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom<br>
<br>
<br>
_______________________________________________<br>
cctbxbb mailing list<br>
</div></div><a href="mailto:cctbxbb@phenix-online.org">cctbxbb@phenix-online.org</a><mailto:<a href="mailto:cctbxbb@phenix-online.org">cctbxbb@phenix-online.org</a>><br>
<a href="http://phenix-online.org/mailman/listinfo/cctbxbb" target="_blank">http://phenix-online.org/mailman/listinfo/cctbxbb</a><br>
<br>
</blockquote></div><br></div></div>