Implement Probe2

[russell-taylor]

Will use the scaffolding program from https://github.com/ReliaSolve/cctbx_project/issues/132 and the command-line arguments (turned into Phil parameters) from https://github.com/reliasolve/cctbx_project/issues/57

[russell-taylor]

parse.[hc] and select.[hc] are used to parse the patterns and to use the patterns to select source and target atoms. There will be a lot of work involved in implementing these. Source and target selections are in Phil parameters.

[russell-taylor]

When not run with -quiet, there is a bunch of boilerplate at the front and back that may be taken into account by existing CCTBX behavior.

[russell-taylor]

It looks like it always expects to output a kinemage format, so maybe we rename the suffix .kin rather than .txt.

[russell-taylor]

(done) Why are we getting more atoms selected/counted in the original code than there are in the whole file for 1xso?

They get added around line 384; before that, we have 2541. By line 400, we have more. It looks like it is updateHydrogenInfo(). Yep, there is a whole hydrogen-addition section that happens unless we're using implicit hydrogens and when we're using moving atoms (but this should not be so when we are calling it on line 394 because we pass NULL for both movingatoms and its bins). Comments say that we can get a list of new atom "clones" which ar just the MainAtoms waters.

Indeed, running with -implicit gets the count back to 2541, and asking for "not resHOH" gives us 2191, which matches CCTBX "not (resname HOH)".

[russell-taylor]

(done) Figure out how to handle HighGoodCut (-divhigh/contact_cutoff); it is selecting contact type in probe and seems to be another level that we don't currently have.

Solved this by breaking the process into two and doing contact type followed by interaction type the same way the original code did.

[russell-taylor]

(done) Implement all of the phil command-line arguments that are in place and all of the approaches.

[russell-taylor]

(done) Implement the phantom hydrogen addition in the conditions that it should happen.

[russell-taylor]

We'll implement arrays based on the atom-type entry (the first entry in the atomprops.h array, implicit index in AtomTypes.py) with a dictionary whose key is the element name; we can traverse the keys in alphabetical order or some other order.

(done) Figure out how to deal with the hack of making atomIdentifiers entries for the various base types for nucleic acids as a way of coloring things by base. This digs deep down into the atom class for each atom. We can handle this by naming them with the non-element names that are used in that table: a, c, t/u, g, other na, and nonbase.

[russell-taylor]

(done) Implement default behavior with no arguments, and the other "macro" arguments

[russell-taylor]

(done) Why are we getting many more surface dots reported on waters than are possible for 1xso:

mmtbx.probe2 output.file_name_prefix=deleteme approach=surface source_selection="water" 1xso_hydrogenate.pdb count_dots=True

probe -outside "WATER" -count -quiet F:\data\Richardsons\1xso.pdb

When we run with -implicit, the new version marks 100% of the 142450 dots on the 350 atoms; the old marks 84.9% of the 14590 dots on the 350 atoms. The new potential area is 8903.1 and the new is 9121.9. The contact surface area is reported the same as the potential in the new, but is different (7741.6) in the old.

For implicit, the new version adds 407 dots per atom, whereas the old adds 417. The new radius is 1.4 whereas the old is 1.5. This is because the new version does not yet know how to ask for implicit radii for atoms.

Running without -implicit, the old code adds 370 dots for 1.4 radius and 212 for 1.05; the new code adds 407 dots for radius 1.4 and none for 1.05 (the Hydrogens). The hydrogens were improperly being excluded from the skin counting. Adding that back in dropped the count to < 100%. It also made the contact surface area different than the potential area.

[russell-taylor]

(done) Why are the dot counts so different between the old and new versions; 370 and 212 vs. 407 and 218 for radius 1.4 and 1.05? Both have density 16.0.

The new code was using the ceiling to find the number of dots rather than the floor. Switched back to floor for easier comparisons.

[russell-taylor]

(done) Enable the new code to ask for the proper +hydrogen radius for atoms when doing implicit hydrogens.

[russell-taylor]

(done) Why do we get 84.9% dots on old and 100% on new when we run with implicit_hydrogens=True atom_radius_scale=1.071428 on new and -implicit on old to get no Phantom hydrogens and 1.5 radius on all Oxygens?

It is because the selected atoms are bumping against non-selected atoms in the original. Modified the new code to behave this way as well.

This produces 95.1% area and the rest of the numbers scale to match this. Presumably, the discrepancy is due to the differences between implicit radii for atoms other than Oxygen not having the same ratio, so our track of scaling the radii doesn't completely mask the fact that the new version is not yet using implicit radii.

Switching the new code to handle implicit hydrogen radii directly and to use old Probe table values still produces 99.4% area rather than 84.9% in the old version. It is correctly placing 417 dots per 1.5-radius hydrogen atoms.

There was an incorrect neighbor radius being used in the calculations of which atoms are neighbors.

[russell-taylor]

(done) Why do we get 61.7% of the dots when we run with explicit hydrogens in the new version but 100.9% in the old?

When we remove the "different parent" check from water-water interactions in the new count, it goes from 61.7 to 126.8%. Looks like they are fratricide between too-many hydrogens on the same Oxygen, presumably because we are not excluding phantoms that might connect to non-Acceptor atoms. (Nope, we are checking for acceptor-only neighbors; maybe there are more acceptor neighbors even with the original Probe tables because we haven't finished all of the adjustment code?)

Fixing bug in check for aromatic ring acceptor atoms did not help much with the counts, so there is something else also going on.

When we adjust the overlap distance in getPhantomHydrogensFor() to make the overlap distance more like what Probe expects than what Reduce expects (we should make this radius and perhaps overlap a parameter) we get about the right number of added hydrogens. However, we then have an incorrect number of potential dots, so maybe we're getting a radius wrong still.

The distances between the atom we're drawing a skin on and the bonded neighbor atoms ranges between 0 (inclusive) and 1 (inclusive) on the new skin counting code. It never gets checked on the old; apparently we never check the hydrogens.

We needed to avoid checking skins for the phantom hydrogens.

[russell-taylor]

(done) Small differences between the overlap calculations in getPhantomHydrogensFor() and old code cause differences in both the number of phantom hydrogens placed and the total number of external dots counted.

Number of dots was due to variation in atom radii.

[russell-taylor]

(done) Figure out how to specify a model to use and how to loop over multiple models when needed.

[russell-taylor]

(done) Figure out how to work properly when run on more than one alternate (no alternate selection) or note that the old one did not so the new one will not yet.

Tested on multiple-alternate file and debugged to get the same results.

[russell-taylor]

(done) Not seeing any hydrogen bond contacts on Probe2, lots more close C contacts, when running probe.exe -implicit -element -gapbins -kin -self ALL -count -quiet F:\data\Richardsons\1xso.pdb vs. mmtbx.probe2 output.file_name_prefix=deleteme approach=self source_selection="all" count_dots=True F:\data\Richardsons\1xso.cif use_original_probe_tables=True implicit_hydrogens=True add_kinemage_keyword=True bin_gaps=True atoms_are_masters=True

How are we seeing hydrogen bonds in that case for old probe -- there are no hydrogens... maybe the -implicit causes a change in counting? It is seeing H bonds between OG and O, and between O and NH1 (which is a Nitrogen) and other pairs, none of which are Hydrogens. Yep... it looks like finding an acceptor and donor makes a hydrogen bond even when they are not Hydrogens.

So we must not be tagging either donors or acceptors the same way in probe2 as in the original probe. But... the only way things seem to be tagged with DONOR_PROP in probe is if they are a Hydrogen.

There is a setProperties() function in select.c in probe that uses the DonorAcceptorAtomTbl structure to determine whether atoms are donors or acceptors along with other tables to determine charge. It is called from the newAtom() function in probe.c.

This is not being called when we're doing the atom info determination using the Probe tables (Reduce did not do this), which is why they are missing. When we use the CCTBX functions to determine donors and acceptors, we get the Hydrogen bonds back.

[russell-taylor]

(done) Output formatting options:

        Output formats needed for Probe besides Kinemage: Do we need -OFORMAT, -XVFORMAT, or -ONELINE?
                 -OFORMAT is not being used, nor -XVFORMAT
                 There is also -U, which sets rawFormat, which a lot of their programs use
                 -CON is being used, maybe one line of unformatted output per interaction, works with -U
                 Also need -oneline

[russell-taylor]

(done) We're getting about 3x as many close contacts for C atoms in 1bti when using the new Reduce (with CCTBX atom information because the original Probe code doesn't yet mark donors, acceptors, and charges) as with the original Probe code. We're also getting about twice as many total overlaps. The total number of Hydrogen bonds, and their total score, is about the same.

When using the ener_lib_molprobity.cif file, which has all atom radii replaced with those from Probe (including ionic radius for vdw radius in metals), we get aligned dots with the old version of probe. We get almost perfect hydrogen bond counts. The number of small overlaps is about 17% larger in probe2. The number of contacts is much larger in probe2(1705 vs. 2501).

There are (1) often a ring of additional dots around the new code not present in the old, (2) rarer rings of additional dots in the old, (3) some dot length/type changes.

These might have to do with the kiss-bullseye code. When we remove the annular-dots code, we don't seem to see a change. The annular-dots code is definitely marking some dots, so it is doing something in the Reduce code, but it may not be checked in the Probe code...

Indeed, we were not checking for annular dots. Adding the check found some dots and excluded them. This visually improved the situation. It also made the counts much closer.

[russell-taylor]

(done) Why are we getting very different contacts in unformatted mode for 1bti? probe -element -unformat -gapbins -self "ALL" -quiet -implicit F:\data\Richardsons\1bti.pdb > C:\tmp\deleteme.kin vs. mmtbx.probe2 output.file_name_prefix=1bti approach=self source_selection="all" count_dots=False implicit_hydrogens=True add_kinemage_keyword=True bin_gaps=True F:\data\Richardsons\1bti.pdb run_tests=True raw=True

We can also run source water vs. not-water and do -once. This shows us that (1) There is an offset of half a strip between the old and new probe code, and (2) There seem to be many more dots in the new Probe than in the old.

The code to compute the dots on a DotSphere seems to identically match the original Probe code. Is there a radial offset that makes it look like there is a phase difference? There may be a slight radial difference, but that is not the main cause of the offset. The fact that the dots move with different step sizes on the sphere may indicate that we're seeing sphere size differences between the two. This might indicate slightly different radii between the atoms in the new and old code. This is to be expected for implicit water, which is what I was looking at (1.52 for CCTBX, 1.50 for Probe).

Manually setting the implicit radius to 1.50 for oxygen got the dots to line up exactly. At that point, the difference was additional dots and some dots changing color, presumably due to the different radii of other atoms.

When running -both with the original 1.52 and then the 1.50, going from 1.52 to 1.50 the number of contacts listed for O's in the water went down and the number of hydrogen bonds went up; this makes sense. The number of wide contacts for C atoms with the waters went down, close contacts went up, small overlap went down (note that there are also perhaps O's bonded to these C's which are now less blocking). For O's in the molecule contacting the O's in the waters, all counts (wide contact, close contact, H bond) went down. The contact surface area of the water went down and the contact surface area of the rest of the molecule went down. The potential areas also went down.

(done) Consider replacing the table that CCTBX uses to determine radii with one that has the original probe values to see if we get the same answers in that case.

Using the ener_lib_molprobity.cif file, which has all atom radii replaced with those from Probe (including ionic radius for vdw radius in metals), we get overlapping dots with the old version of probe. There are (1) often a ring of additional dots around the new code not present in the old, (2) rarer rings of additional dots in the old, (3) some dot length/type changes. This did seem to make all of the dots line up.

When we do the "not water" against water, we still find probe dot offsets (presumably indicating radius differences) for some Ca, Cb and Cg atoms. O and N atoms and a C atom were okay. The implicit radii for carbons had not been adjusted along with the others. When that adjustment was made, the dots lined up.

(done) There is still misalignment on CB BARG 53 A. It was caused by not checking for compatible conformations when adding bonded neighbor atoms.

[russell-taylor]

(done) Why do we get no mainchain-sidechain counts in: mmtbx.probe2 output.file_name=1bti.kin approach=self source_selection="all" count_dots=False implicit_hydrogens=True add_kinemage_keyword=True bin_gaps=True F:\data\Richardsons\1bti.pdb format=standard approach=self output.contact_summary=True

We're never getting into the state where we're adding +1 to it, on line 648; we dot get into the MCMC and SCSC states within that same block.

We were not properly initializing the side-chain property; we were setting it based on the mainchain property.

[russell-taylor]

(done) Add long-form description like the original probe help had saying how to run the various versions of the program, including example simple dotkins and such.

[russell-taylor]

(done) We fail when doing explicit (but not with implicit) hydrogens doing all atoms on 1xso: mmtbx.probe2 approach=self source_selection="all" output.file_name=out.kin F:\data\Richardsons\1xso.pdb

The mainchain and sidechain entries were not being set for added Hydrogens

[russell-taylor]

(done) Finish testing the factor branch against the native-molprobity branch and merge when they behave the same for -self and -once.

The removal of the 'animate' line is expected, but the changing of dot types from S to P and P to O or M is not.

The ptmaster values are being set differently around line 650 for the two versions. Checked the setting for CA whenever it showed up and it was different in the two versions.

The n sidechain/mainchain value is flipping between the two cases.

The atom names are coming out differently; possibly in a different order. The order of the neighbors is changing but the order of the source atoms may be staying the same.

By sorting the outputs that list the types of interactions along with their names and IDs, it is clear that we're seeing a different set of interactions in the two cases. Some of the interactions are the same. There are differences between the sets of interacting atoms between the two runs; there are interactions in one that are not in the other and vice-versa. It looks like the identity of the neighbor atom is changing and we're getting the same number of dots.

(done) We've got a big problem inside the code block that computes interactions -- we're using a leftover n value rather than finding the actual atom being interacted with (res.cause). It is not clear what is making these be different in the two cases, but the basic code is broken.

After fixing that so that we use the cause to determine the behavior, it looks like we're still getting re-ordering of the lines in the files but they seem to be much more consistent.

[russell-taylor]

(done) Even after the above fix, we're getting a small number of interaction differences (which we can see by sorting the files). These appear to be due to getting different vectors in some cases. Varying the strings used to check for class types also causes re-ordering, which causes further differences in the vectors even within the new code. (wrong) Looks like we're seeing a random number seed change based on the code checksum, and also seeing an order effect on the checks.

When we re-run the code, it provides its output in a different order each time. This is fortunate because it lets us look for the cause of the order effect.

There are the same number of dots in each run, and the dots fall into the same categories (MCMC, etc.) between runs. But the dots are listed in a different order and they sometimes have different lengths between runs.

The differences are fairly far down in the file. They are often block replacements of identical text (different ordering or src atoms). Sometimes they are elements at the beginning of a source record that go missing. Once they started in the middle of a src record (maybe grabbing some of the missing elements grabbed from the starts).

The differences only happen on Hydrogens added to waters. When we run with implicit hydrogens, we see no differences.

The i_seq numbers for the added Hydrogens match the numbers for the atoms they are being added to...

Setting the i_seqs to zero (default) will alias them all to the ID of the first atom in the file. Running reset_atom_i_seqs() will cause us to redo some or all of the code that got us where we are (like the atom selection in the first place). Consider adding phantom hydrogens to all atoms rather than just selected atoms -- we'll then need to cause them to show up in the selection again for general selection criteria iff their Oxygen has been selected. Maybe could add a single Phantom Hydrogen to the model at loading time and then make the duplicates based off it, so they all have the same sequence ID.

Sorting the source and target atoms by memory_id() rather than i_seq does not change the number of differences (when their IDs match the atoms they are bonded to).

Adding a call to _condense() in the writeOutput routine seems to scramble things much worse.

Looking at raw output and the default selection (altid blank or a) still has things out of order. At the beginning, they are grouped by target atom but the target atoms are reordered (as expected, since memory_id() is not maintained between runs). However, sorting them shows that they are the same. It looks like we may be seeing formatting changes between lines when the first line has the atom name and the second has " to indicate that it has not changed.

The memory IDs of the later-allocated Hydrogens being different is presumably what is causing the reordering when they are present that is not there when they are not present. They also seem to somehow be adjusting the order in the un-condensed output.

Indeed, if we strip out the part of the line that has the name of the thing at the beginning and then sort, we get the same files -- so we're seeing the same records just in different order.

[russell-taylor]

(done) We seem to be getting big clashes between atoms and their alternate locations.

Added a check.

[russell-taylor]

(done) We get a bunch of rings around the borders of bonded atoms.

This was because the excluded atoms were included in the list of neighbor atoms. We were seeing the dots that were near but not inside them. Fixed by removing these atoms from those being considered as neighbors while leaving them in the excluded list.

[russell-taylor]

(done) We seem unable to specify the default source selection on the command line. It always complains about something near "(" and it seems to add a space before the ")" along the way somewhere in PHIL processing, which may or may not matter.

These had to be of type atom_selection rather than type str.

[russell-taylor]

(done) We're getting a lot of internal contacts between atoms that don't have contacts in old probe when doing self contacts with 1bt1 "not water" with explicit hydrogens. These are not near the waters.

mainchain-mainchain atoms were not properly being ignored -- only when they were in the same residue not when they were in the same chain.

[russell-taylor]

(done) Check the donor/acceptor and charge values between the atoms in Probe/Reduce vs. CCTBX. Radii differences should be gone, and that can be verified.

Radial differences are gone, but we have a number of donor and two acceptor (on water hydrogens) changes.

Fixing this will require doing the same hydrogen fixup that happens inside Probe2 within Reduce, so we presumably want to move this into Helpers and call it from both along with getPhantomHydrogens.

Factored out the donor changes, which got the adjustments correct on the A conformations but did not get them correct on the B conformations. Both the Hydrogens and the original atoms are skipped in new Reduce in terms of swapping their donor statuses. This is presumably because it has dumped the atom file for each alternate in reverse order, ending with alt A. In that case, it did not adjust atoms in the B alternate.

We still have two water Oxygens marked as acceptors in the new that are not marked as acceptors in the old. It is not clear why the old version did not mark these as acceptors. Checking with Jane.

[russell-taylor]

(done) Make sure we're only putting hydrogens towards acceptors in probe2 (can make this an option in the code that places hydrogens).

[russell-taylor]

(done) Looks like we may need the option to keep or not keep the unselected atoms and handle it appropriately. This could make the solvent-accessible surface draw all dots, for example.

[russell-taylor]

(done) Check on writing the name of the group into the kinemage file when group_name=SCS is defined; it was in probe but not in probe2.

It is named in the same "group dominant" command in both of them. The caption entry is missing in probe2, which is a bit of a mystery.

Fixed by adding extra {{ and }} to cause the { and } to show up in the Python code.

[russell-taylor]

(done) With 1bti, it looks like the scssurface code in old probe puts some dots on an atom that is inside another atom that has dots on it, and has other significant differences between the old and new. Not sure which has the bug.

These may depend on the treatment of alternate conformations? But both had A selected; check by clicking.

probe -scsurface -quiet F:\data\Richardsons\1bti.pdb > C:\tmp\1bti_scsurface.kin

mmtbx.probe2 output.file_name=1bti_scsurface_new.kin F:\data\Richardsons\1bti.pdb add_kinemage_keyword=True approach=surface source_selection="not water" probe.radius=1.4 group_name="SCS" keep_unselected_atoms=False

This is due to the fact that we see interactions with the water O in addition to interactions with the Phantom Hydrogens. Modified the new code to behave the same way as the old and made another issue to consider switching this behavior.

[russell-taylor]

(done) the @caption entry is missing in the surface approach on Probe2.

[russell-taylor]

(done) See if the hydrogens are placed in the same place for explicit hydrogens in the new code and the original code now that we're only pointing them at acceptors. There are currently more Hydrogens placed in the new code than the old for 1bti, for example.

Dumping the hydrogen vectors shows largely the same vectors, with the following differences: (1) The hydrogens are placed very slightly further from the Oxygens in the old code. (2) There are additional hydrogens shown in the new that are not in the old; most of these are from Oxygens that already have bonds in the old, but which point in different directions.

The new hydrogens are a superset of the old hydrogens.

Making the WATER_EXPLICIT_RADIUS in Helpers.py:getPhantomHydrogensFor() 1.0 rather than 1.05 made the lengths identical.

(done) Find out from Jane which one to use (probe version vs. reduce version) going forwards. We want to use the appropriate bond length depending on whether we're using neutron distances or electron-cloud distances.

Are we seeing a different radius used to check for nearby atoms in the two cases, causing us to pull in more atoms in the new code due to a longer distance? When we subtract 0.1 from the overlap, we get the expected number and list of hydrogens, but most of their lengths get changed by 0.1. Modifying the threshold from 0.001 to 0.1 fixed the issue -- looks like that value was mis-typed.

[russell-taylor]

(done) Hydrogen bonds are much less prevalent in 1bti in new rather than old. It looks like at least some of the Hydrogens are much closer to the Oxygen centers in the new system.

probe -quiet -mc -once "water" "not water" -kin F:\data\Richardsons\1bti.pdb > 1bti_old.kin

mmtbx.probe2 output.file_name=1bti_new.kin F:\data\Richardsons\1bti.pdb count_dots=False format=standard add_kinemage=True approach=once source_selection="water" target_selection="not water"

It looks like we're getting "hydrogen bonds" with the oxygens even in directions that there are not phantom hydrogens and that we're getting clashes with hydrogens where we should be getting hydrogen bonds. Maybe the donor/acceptor flagging is not being done properly when adding hydrogens.

The result of check_dot is a clash even when the source atom is a dummy hydrogen. This is because the code is not checking for whether the source is a dummy hydrogen (that never happened with Reduce). Check for source being a dummy hydrogen and constructing the DotScorer after the phantom hydrogen addition got rid of all but one clash... modified it to also skip too-close hydrogen bonds when either is a phantom and that fixed the final one.

(done) We're getting a slight superset of hydrogen bond dots for the new case beyond those due to additional hydrogens. In at least one case, it is one phantom hydrogen being inside another and both colliding with an atom. Adding bonds from the oxygen to the phantom hydrogens handles these (but excludes close contacts from oxygens behind phantom hydrogens (done) how do we want to handle this), but there are still some patches inside or on the edge of atoms. Are these due to bonded neighbors of the far atoms that should be excluded? Modified the source phantom exclusion code to handle this case, but still not seeing it. It does seem likely that the dots are also inside another atom for at least one case judging from the surface dots. The potentially blocking atoms have full occupancy and low B factor, so should not be excluded by that. Maybe increase the search radius... that did not seem to help.

(done) We're also getting small-overlap dots behind the phantom hydrogens in the old Probe that are probably from the oxygen (not being properly excluded by the phantom hydrogen) that no longer show up in the new code once we count them as neighbors. Asked Jane how to handle these.

[russell-taylor]

(done) Is the bullseye code being run on hydrogen-bond phantoms? We're seeing VDW contacts in a ring around one hydrogen bond candidate.

[russell-taylor]

(done) Consider whether include_het and include_water (but not include_water_water) should be removed as parameters because they can be specified in the selection criteria. Think about how this will change behaviors. NOTE: these were handled in the source-selection code in the original Probe so if we're going to make them work here we need to add to the selection strings to make this happen or else do another pass through the selections to remove them.

Removed them; they can be specified in the source and/or target selection strings as desired.

[russell-taylor]

(done) When doing -both with 1bti, we get 2->1 dots in a corner of three atoms on CYS 30 in chain A in the old Probe that we don't get in the new. It looks like maybe the Oxygen and Phantom Hydrogen are shielding each other. Probably because one of them is marked as bonded to the other...

Nope, removing the bond from the Hydrogen didn't fix it. Perhaps the Phantom Hydrogen is blocking the bonds coming back the other way from the non-Acceptor atoms (N and CB).

[russell-taylor]

(done) We're getting extra dots around phantom hydrogen bonds. They are marked as hydrogen bonds internally but they are not touching, and the hydrogen-bond nature does not escape the Scoring. However, they should be considered annular and so removed... not annular, but exterior hydrogen bonds when we're not considering weak hydrogen bonds.

The hydrogen-bond nature does not get returned by check_dot(), which it needs to for it to be properly categorized later. This may be a difference in behavior between Probe and Reduce, where Reduce may not have counted weak Hydrogen bonds. Yep -- there is special code in Probe to mark this as a Hydrogen bond in the case that weak hydrogen bonds are being used. Looks like we need to make that a constructor parameter and change the behavior of check_dot along with interaction_type.

[russell-taylor]

(done) Getting twice as many dots on A and B alternates for old probe on 1bti CB AARG 53 and CB BARG 53 from a phantom hydrogen for "water" and "not water". In both cases, we get dots on both alternates but we only have half as many dots in the new code. These are in the 2:1 direction, drawing on the surface of the CB.

It looks like the atoms are excluding one another in the new code; we're seeing A on one side and B on the other. The bonded-neighbor code is not checking to make sure that the bonded atoms are on a consistent chain...

Modified it to check for that and the new code now behaves the same as the old.