Since Keren is too shy to ask, where it should go, I will. I propose an "applications" directory which than would have a dir per app. Then data and example scripts can go with it. Alternatives?
Daniel Russel wrote: > Since Keren is too shy to ask, where it should go, I will. I propose an > "applications" directory which than would have a dir per app. Then data > and example scripts can go with it. Alternatives?
Sounds reasonable, although surely the applications would come in at least three flavors: C++ command line binaries, Python scripts and packages, and web services. It probably makes sense to lump the first two together in the applications directory (since we may mix and match anyway - look at EMAN for an example) but web services are a rather different beast, so should probably go elsewhere when we implement them.
Of course, this only works for applications that we intend to distribute. Other such applications should live in a different repository (impmod would be the most obvious location).
As an aside, applications should not implement basic functionality but should instead combine functionality from IMP modules, perhaps with specific data sets. For example, if the calculation of an EM fit required you to use an "em_fit" application, it would be very hard to combine this fit with other IMP restraints. Instead, the EM fit should be calculated by the IMP.em module (as it is) and the "em_fit" application should just wrap this functionality, perhaps with some nice user interface.
Ben
On May 22, 2009, at 1:29 PM, Ben Webb wrote:
> Daniel Russel wrote: >> Since Keren is too shy to ask, where it should go, I will. I >> propose an >> "applications" directory which than would have a dir per app. Then >> data >> and example scripts can go with it. Alternatives? > > Sounds reasonable, although surely the applications would come in at > least three flavors: C++ command line binaries, Python scripts and > packages, and web services. It probably makes sense to lump the first > two together in the applications directory (since we may mix and match > anyway - look at EMAN for an example) but web services are a rather > different beast, so should probably go elsewhere when we implement > them. > > Of course, this only works for applications that we intend to > distribute. Other such applications should live in a different > repository (impmod would be the most obvious location). > > As an aside, applications should not implement basic functionality but > should instead combine functionality from IMP modules, perhaps with > specific data sets. For example, if the calculation of an EM fit > required you to use an "em_fit" application, it would be very hard to > combine this fit with other IMP restraints. Instead, the EM fit should > be calculated by the IMP.em module (as it is) and the "em_fit" > application should just wrap this functionality, perhaps with some > nice > user interface. yes - I totally agree. It is just not fully clear to me if em_fit should be part of helper or em ? > > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: > It is just not fully clear to me if em_fit should be part of helper > or em ?
Well, it was a hypothetical application, but... neither. Calculation of an EM fit should go in the IMP.em module, of course. But if you wanted to write a little command line application that took a PDB and a density map from the user and reported the CCF, for example, that would go in the 'applications' directory, not in the IMP.em module. (The important point is that the bulk of the functionality - i.e. reading a PDB file, reading an EM map, calculating the CCF - should stay in IMP.atom and IMP.em where it currently is, so that other applications or modules can use it.) I don't think anything EM-related should go in IMP.helper, since we don't want to end up with too many interdependencies between the modules.
Ben
On May 22, 2009, at 11:10 PM, Ben Webb wrote:
> Keren Lasker wrote: >> It is just not fully clear to me if em_fit should be part of helper >> or em ? > > Well, it was a hypothetical application, but... neither.
it is not a hypothetical one - because I am actually trying to wrap it up these days .... ;)
> Calculation of > an EM fit should go in the IMP.em module, of course. But if you wanted > to write a little command line application that took a PDB and a > density > map from the user and reported the CCF, for example, that would go in > the 'applications' directory, not in the IMP.em module. (The important > point is that the bulk of the functionality - i.e. reading a PDB file, > reading an EM map, calculating the CCF - should stay in IMP.atom and > IMP.em where it currently is, so that other applications or modules > can > use it.) I don't think anything EM-related should go in IMP.helper, > since we don't want to end up with too many interdependencies between > the modules. yes - I just was not sure where we draw the line between stuff that should be helper vs. in modules. I think that Daniel meant for the modules to have just a very basic functionality, although I agree that rigid fitting should go in EM. I guess that the decision would be on a case-to-case basis, for example flexible fitting should probably go directly to application and not to em. > > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: > yes - I just was not sure where we draw the line between stuff that > should be helper vs. in modules.
helper is also a module - it's just a higher level interface. So something general that pulls in functionality from several classes (possibly in several modules) could go there. But something that is obviously EM-related should live in IMP.em.
> I think that Daniel meant for the modules to have just a very basic > functionality, although I agree that rigid fitting should go in EM.
Well, it depends whether you define "rigid fitting" as "fitting into an EM density map" (in which case it lives in IMP.em) or "fitting into some kind of map" (in which case maybe it should go in a separate module).
> I guess that the decision would be on a case-to-case basis, for example > flexible fitting should probably go directly to application and not to em.
Perhaps. It is always possible to refactor and move things out of an application into a module if we really want to be able to use them elsewhere, of course.
Ben
Helper is explicitly high level functionality built on top of other modules, so it is likely to depend on everything ultimately. My thought was that she wanted a function that took a bunch of pdbs and a map and does rigid fitting. Assuming that is a common operation that should be outside of an application, helper makes sense, IMHO.
On May 22, 2009, at 11:10 PM, Ben Webb ben@salilab.org wrote:
> Keren Lasker wrote: >> It is just not fully clear to me if em_fit should be part of helper >> or em ? > > Well, it was a hypothetical application, but... neither. Calculation > of > an EM fit should go in the IMP.em module, of course. But if you wanted > to write a little command line application that took a PDB and a > density > map from the user and reported the CCF, for example, that would go in > the 'applications' directory, not in the IMP.em module. (The important > point is that the bulk of the functionality - i.e. reading a PDB file, > reading an EM map, calculating the CCF - should stay in IMP.atom and > IMP.em where it currently is, so that other applications or modules > can > use it.) I don't think anything EM-related should go in IMP.helper, > since we don't want to end up with too many interdependencies between > the modules. > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
she=keren I guess so: Once we will resolve the set_transformation issue I intend to submit the rigid fitting procedure into the svn as follows: 1. rigid_fitting(RigidBody, DensityMap) - will be in EM 2. the code that takes the pdb file and makes an IMP rigid body out of it will be in helpers 3. the code that calls these two functions function and writes out the transformations and scores will be in application. sounds good ? On May 25, 2009, at 4:59 PM, Daniel Russel wrote:
> Helper is explicitly high level functionality built on top of other > modules, so it is likely to depend on everything ultimately. My > thought was that she wanted a function that took a bunch of pdbs and > a map and does rigid fitting. Assuming that is a common operation > that should be outside of an application, helper makes sense, IMHO. > > > > On May 22, 2009, at 11:10 PM, Ben Webb ben@salilab.org wrote: > >> Keren Lasker wrote: >>> It is just not fully clear to me if em_fit should be part of helper >>> or em ? >> >> Well, it was a hypothetical application, but... neither. >> Calculation of >> an EM fit should go in the IMP.em module, of course. But if you >> wanted >> to write a little command line application that took a PDB and a >> density >> map from the user and reported the CCF, for example, that would go in >> the 'applications' directory, not in the IMP.em module. (The >> important >> point is that the bulk of the functionality - i.e. reading a PDB >> file, >> reading an EM map, calculating the CCF - should stay in IMP.atom and >> IMP.em where it currently is, so that other applications or modules >> can >> use it.) I don't think anything EM-related should go in IMP.helper, >> since we don't want to end up with too many interdependencies between >> the modules. >> >> Ben >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: > she=keren I guess so: > Once we will resolve the set_transformation issue I intend to submit the > rigid fitting procedure into the svn as follows: > 1. rigid_fitting(RigidBody, DensityMap) - will be in EM > 2. the code that takes the pdb file and makes an IMP rigid body out of > it will be in helpers > 3. the code that calls these two functions function and writes out the > transformations and scores will be in application. > sounds good ?
Right - sounds good to me.
Ben
On May 25, 2009, at 5:04 PM, Keren Lasker wrote:
> she=keren I guess so: Indeed, was writing from my phone :-)
> Once we will resolve the set_transformation issue I intend to submit > the rigid fitting procedure into the svn as follows: > 1. rigid_fitting(RigidBody, DensityMap) - will be in EM > 2. the code that takes the pdb file and makes an IMP rigid body out > of it will be in helpers > 3. the code that calls these two functions function and writes out > the transformations and scores will be in application. > sounds good ? > On May 25, 2009, at 4:59 PM, Daniel Russel wrote: > >> Helper is explicitly high level functionality built on top of other >> modules, so it is likely to depend on everything ultimately. My >> thought was that she wanted a function that took a bunch of pdbs >> and a map and does rigid fitting. Assuming that is a common >> operation that should be outside of an application, helper makes >> sense, IMHO. >> >> >> >> On May 22, 2009, at 11:10 PM, Ben Webb ben@salilab.org wrote: >> >>> Keren Lasker wrote: >>>> It is just not fully clear to me if em_fit should be part of helper >>>> or em ? >>> >>> Well, it was a hypothetical application, but... neither. >>> Calculation of >>> an EM fit should go in the IMP.em module, of course. But if you >>> wanted >>> to write a little command line application that took a PDB and a >>> density >>> map from the user and reported the CCF, for example, that would go >>> in >>> the 'applications' directory, not in the IMP.em module. (The >>> important >>> point is that the bulk of the functionality - i.e. reading a PDB >>> file, >>> reading an EM map, calculating the CCF - should stay in IMP.atom and >>> IMP.em where it currently is, so that other applications or >>> modules can >>> use it.) I don't think anything EM-related should go in IMP.helper, >>> since we don't want to end up with too many interdependencies >>> between >>> the modules. >>> >>> Ben >>> -- >>> ben@salilab.org http://salilab.org/~ben/ >>> "It is a capital mistake to theorize before one has data." >>> - Sir Arthur Conan Doyle >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (3)
-
Ben Webb -
Daniel Russel -
Keren Lasker