Netiquette · Download · News · Gallery · G-quadruplexes · DSSR-Jmol · DSSR-PyMOL
· Video Overview · DSSR v2.5.2 (DSSR Manual) · Homepage
-
Hi Xiang-Jun,
I have just downloaded the latest version of 3DNA dated October 16 for Intel Mac.
I have OS X 10.8.2 (Lion) on a MacBookPro 9.2.
When running find_pair i get the following output:
find_pair 1ehz.pdb 1ehz.inp ──(Wed,Oct24)─┘
handling file <1ehz.pdb>
uncommon residue 2MG 10 on chain A [#10] assigned to: g
uncommon residue H2U 16 on chain A [#16] assigned to: u
uncommon residue H2U 17 on chain A [#17] assigned to: u
uncommon residue M2G 26 on chain A [#26] assigned to: g
uncommon residue OMC 32 on chain A [#32] assigned to: c
uncommon residue OMG 34 on chain A [#34] assigned to: g
uncommon residue YYG 37 on chain A [#37] assigned to: g
uncommon residue PSU 39 on chain A [#39] assigned to: P
uncommon residue 5MC 40 on chain A [#40] assigned to: c
uncommon residue 7MG 46 on chain A [#46] assigned to: g
uncommon residue 5MC 49 on chain A [#49] assigned to: c
uncommon residue 5MU 54 on chain A [#54] assigned to: u
uncommon residue PSU 55 on chain A [#55] assigned to: P
uncommon residue 1MA 58 on chain A [#58] assigned to: a
open_file <./Atomic.g.pdb> failed: No such file or directory
I thought this was a problem related to not including config in the path and added $X3DNA/config to the path, unsuccessfully.
So 1ehz.inp, with the base-pairing results is not produced as output.
Other commands such as, get_part, work well.
Thanks once more,
Mauricio
-
Hi Mauricio,
Thanks for your report. I can reproduce the 'problem'; it has nothing to do with including $X3DNA/config in the environment settings.
The error message:
open_file <./Atomic.g.pdb> failed: No such file or directorymeans 3DNA (find_pair) is trying to locate the file in your current working directory (CWD), instead of the default system setting $X3DNA/config where the file Atomic.g.pdb is available, among other Atomic*.pdb files.
If file Atomic_A.pdb exists in your CWD, 3DNA assumes all other Atomic*.pdb files there as well. That's normally true if you run, e.g.:
x3dna_utils cp_std bdna
For your case, you must have Atomic_A.pdb and possibly several other canonical base Atomic_[CGTU].pdb files in your CWD, but not the modified version (in lower case, prefixed with a dot instead of underscore). So simply run the following command in you CWD will do the trick:
cp -f $X3DNA/config/Atomic.*.pdb .
Alternatively, you can delete all the Atomic*pdb files from your CWD, and find_pair will work as expected:
rm -f Atomic*.pdb
find_pair 1ehz.pdb stdout
Please have a try and report back how it goes.
I may consider to refine 3DNA to check for each Atomic*.pdb file separately, but that would complicate the code. You are actually the first to notice this 'limitation'. Practically, knowing what's happening behind the scene, you can easily work around it, as suggested above.
HTH,
Xiang-Jun
-
Hi Xiang-Jun,
That was exactly the problem. :)
Thanks
I deleted the canonical bases Atomic_[CGTU].pdb, and it works with no problem.
Or also by just running the new:
x3dna_utils cp_std BDNA
Beforehand.
Mauricio
-
As a follow up, as of 3DNA v2.1 2012oct26, your initial problem has been solved. Now you can have for example only Atomic_A.pdb in your current working directory, and 3DNA will use that file; for the Atomic*.pdb files not found in the current directory, 3DNA will use the default in $X3DNA/config. Overall, this revision allows 3DNA users greater flexibility in choosing the standard base-reference-frame files for analysis and rebuilding.
Xiang-Jun
Funded by the NIH R24GM153869 grant on X3DNA-DSSR, an NIGMS National Resource for Structural Bioinformatics of Nucleic Acids
Created and maintained by Dr. Xiang-Jun Lu, Department of Biological Sciences, Columbia University