[cctbxbb] [Dials-support] DIALS source tarball

Wed Apr 8 03:06:26 PDT 2015

Sadly this also does not fix anything :o( not sure why this was not flagged when I configured chem_data...

libtbx.python "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py" [FAIL]
  Time:  6.44
  Return code: 1
  OKs: 0
  Standard error:
    Traceback (most recent call last):
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 866, in <module>
        exercise_all(sys.argv[1:])
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 862, in exercise_all
        exercise_na_restraints_output_to_geo(verbose=verbose)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 818, in exercise_na_restraints_output_to_geo
        log=out2)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 5274, in run
        nonbonded_distance_threshold=nonbonded_distance_threshold)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 4952, in geometry_restraints_manager
        ss_manager.initialize(log=self.log)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 280, in initialize
        self.find_automatically(log=log)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 313, in find_automatically
        self.sec_str_from_pdb_file = self.find_sec_str(log=log)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 369, in find_sec_str
        (records, stderr) = run_ksdssp_direct(pdb_str)
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 728, in run_ksdssp_direct
        exe_path = get_ksdssp_exe_path()
      File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 709, in get_ksdssp_exe_path
        raise RuntimeError("ksdssp module is not configured")
    RuntimeError: ksdssp module is not configured

On 8 Apr 2015, at 11:02, <richard.gildea at diamond.ac.uk<mailto:richard.gildea at diamond.ac.uk>> <richard.gildea at diamond.ac.uk<mailto:richard.gildea at diamond.ac.uk>> wrote:

$ du -h --max-depth=0 chem_data

1.6G chem_data

Not sure we really want to include this in the dials builds, just to make one test happy, especially when we have no use for any of the monomer library functionality in dials.

Cheers,

Richard

________________________________
From: Graeme Winter [graeme.winter at gmail.com<mailto:graeme.winter at gmail.com>]
Sent: 08 April 2015 10:58
To: Gildea, Richard (DLSLtd,RAL,LSCI); Gerstel, Markus (DLSLtd,RAL,LSCI); asbrewster at lbl.gov<mailto:asbrewster at lbl.gov>; cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org>
Cc: dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net>
Subject: Re: [Dials-support] [cctbxbb] DIALS source tarball

can we add this to the dials build through some kind of tarball download which does not need a cci account?

Thanks graeme

On Wed, Apr 8, 2015 at 10:52 AM <richard.gildea at diamond.ac.uk<mailto:richard.gildea at diamond.ac.uk><mailto:richard.gildea at diamond.ac.uk>> wrote:
Hi Markus,

I agree that it would be better if the tests would either work gracefully with CCP4 monomer library, or (possibly better?) only run if chem_data is available. In the latter case, a simple libtbx.env.has_module("chem_data") could be used in the test to check whether chem_data is available.

As a workaround, we developers should be able to add the chem_data repository to our sources after which the tests should pick up the correct version of the monomer library:

$ svn co svn+ssh://[email protected]/chem_data/trunk<http://[email protected]/chem_data/trunk> chem_data
$ libtbx.configure chem_data

Cheers,

Richard
________________________________________
From: Gerstel, Markus (DLSLtd,RAL,LSCI)
Sent: 08 April 2015 09:33
To: Gildea, Richard (DLSLtd,RAL,LSCI); asbrewster at lbl.gov<mailto:asbrewster at lbl.gov><mailto:asbrewster at lbl.gov>; cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org><mailto:cctbxbb at phenix-online.org>
Cc: dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net><mailto:dials-support at lists.sourceforge.net>
Subject: RE: [Dials-support] [cctbxbb]  DIALS source tarball

Hi Richard,

I think you've found it. I have unset CLIBD_MON, and now the test skips cleanly. Of course this also means that users should not run cctbx tests on their machines...

Is there no central 'mmtbx_skip_test_if_chem_data_db_missing' function, that just goes 'prints "Skip this test"; exit' if the library isn't present?
Or a boolean _is_available() function if you prefer. Either would resolve this problem as well as the current untestability of mmtbx.

-Markus

-----Original Message-----
From: Gildea, Richard (DLSLtd,RAL,LSCI)
Sent: 08 April 2015 09:15
To: Gerstel, Markus (DLSLtd,RAL,LSCI); asbrewster at lbl.gov<mailto:asbrewster at lbl.gov><mailto:asbrewster at lbl.gov>; cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org><mailto:cctbxbb at phenix-online.org>
Cc: dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net><mailto:dials-support at lists.sourceforge.net>
Subject: RE: [Dials-support] [cctbxbb] DIALS source tarball

Hi Markus,

Presumably the test is looking for a monomer that is present in chem_data but not in the ccp4 monomer library? Could we unset the CLIBD_MON variable for the purposes of testing the dials installers?

Cheers,

Richard

________________________________________
From: Gerstel, Markus (DLSLtd,RAL,LSCI)
Sent: 08 April 2015 09:07
To: Gildea, Richard (DLSLtd,RAL,LSCI); asbrewster at lbl.gov<mailto:asbrewster at lbl.gov><mailto:asbrewster at lbl.gov>; cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org><mailto:cctbxbb at phenix-online.org>
Cc: dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net><mailto:dials-support at lists.sourceforge.net>
Subject: RE: [Dials-support] [cctbxbb]  DIALS source tarball

Hi Richard, Aaron,

This is correct, we do not currently run mmtbx tests at all, as up to 107 of them do not fail gracefully, ie. skip properly.

The test in question works fine (ie: is skipped because CCP4 is not made available) on our cctbx test system, but breaks in our final dials installer tests (where CCP4 is made available). CLIBD_MON is set to the /lib/data/monomers folder in the shared DLS CCP4 6.5 update 1 installation.

Best wishes,

Markus

-----Original Message-----
From: richard.gildea at diamond.ac.uk<mailto:richard.gildea at diamond.ac.uk><mailto:richard.gildea at diamond.ac.uk> [mailto:richard.gildea at diamond.ac.uk<mailto:richard.gildea at diamond.ac.uk>]
Sent: 07 April 2015 21:36
To: asbrewster at lbl.gov<mailto:asbrewster at lbl.gov><mailto:asbrewster at lbl.gov>; cctbxbb at phenix-online.org<mailto:cctbxbb at phenix-online.org><mailto:cctbxbb at phenix-online.org>
Cc: dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net><mailto:dials-support at lists.sourceforge.net>
Subject: Re: [Dials-support] [cctbxbb] DIALS source tarball

Hi Aaron,

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).

Cheers,

Richard

________________________________
From: Aaron Brewster [asbrewster at lbl.gov<mailto:asbrewster at lbl.gov><mailto:asbrewster at lbl.gov>]
Sent: 07 April 2015 20:29
To: cctbx mailing list
Cc: Waterman, David (STFC,RAL,SC); Gildea, Richard (DLSLtd,RAL,LSCI); Johan Hattne; <dials-support at lists.sourceforge.net<mailto:dials-support at lists.sourceforge.net><mailto:dials-support at lists.sourceforge.net>>
Subject: Re: [cctbxbb] [Dials-support] DIALS source tarball

Hi Markus, two points.

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.

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?

Thanks,
-Aaron

On Tue, Apr 7, 2015 at 6:41 AM, <markus.gerstel at diamond.ac.uk<mailto:markus.gerstel at diamond.ac.uk><mailto:markus.gerstel at diamond.ac.uk><mailto:markus.gerstel at diamond.ac.uk<mailto:markus.gerstel at diamond.ac.uk>>> wrote:
Cc'ing cctbx folks

David Waterman wrote:
So maybe once we have a source tarball up at
dials.diamond.ac.uk<http://dials.diamond.ac.uk><http://dials.diamond.ac.uk><http://dials.diamond.ac.uk> (..)

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.
So far I could not figure out how to get this running properly.

Call:

libtbx.python tst_geometry_restraints_2.py

Standard Output

Skipping exercise_with_zeolite(): input file not available Skipping exercise_with_pdb(): chem_data directory not available

Standard Error

Traceback (most recent call last):
 File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 866, in <module>
   exercise_all(sys.argv[1:])
 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
   exercise_na_restraints_output_to_geo(verbose=verbose)
 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
   log=out1)
 File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 5270, in run
   log=log)
 File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 4876, in __init__
   restraints_loading_flags=restraints_loading_flags,
 File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2902, in __init__
   log=log,
 File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2287, in __init__
   m_j=mm)
 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
   return mon_lib_srv.link_link_id_dict["rna3p"]
KeyError: 'rna3p'

(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.)

-Markus

--
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.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
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.
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

------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
DIALS-support mailing list
DIALS-support at lists.sourceforge.net<mailto:DIALS-support at lists.sourceforge.net><mailto:DIALS-support at lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dials-support