Re: [Adun-users] Unable to link system H2OContainer

can we have an estimation on when this will be ready, according to everybody's 
workload?


On Jan 19, 2012, at 6:18 PM, Michael Johnston wrote:

> 
> 
> 2012/1/19 Jordi Villà i Freixa <[EMAIL PROTECTED]>
> I am not pretty sure I follow your arguments guys, but here is how I see it
> 
> -the fact that we have a single datasource file for both topology and 
> coordinates is problematic, but we can live with that.
> 
> -the only thing that is needed is that after each calculation (call it 
> minimisation, MD run, or whatever) the program finnishes cleanly by creating 
> a new datasource with a new name, containing all new coordinates and 
> velocities (in addition to the topology, of course). That name can be 
> automatically assigned from Adun if the user does not provide it in the 
> template. Essentially, as a general rule, a template should contain aways the 
> names of the files that are used as input plus the names of the files that 
> will appear as outputs.
> 
> -the difficulty appears to be in reading the datasource that has been 
> previously produced and use it in a new simulation. That should not be a 
> problem as the only needed think is to reapply the SCAAS to the new 
> datasource. Recall the SCAAS affects differently the molecules in the water 
> container than the moleucles in the protein. For these, there is no such 
> think as SCAAS but only a constraint if they are lying outside the sphere. 
> This is the only thing that needs to be fixed right now.
> 
> The difficulty is not in what you describe above - there is some trickyness 
> with the water container - but this still can be overcome
> 
> To summarise, everything you say above is already possible - the linking we 
> discuss just streamlines/automagics the above process for you. It is also 
> more flexible - you don't have to create new input files with 
> coordinates/velocities from just the last frame - you can initialise from any 
> frame in any simulation (of the same protein of course).
>  
> 
> In other words, a datasource contains topology info that should be considered 
> unmutable (unless we want to discuss reactivity, which is not the case by 
> now). The coordinates, currently in the datasource, are the only thing that 
> mutates. Rcall that this differes from other well established packages where 
> topology and coordinates are in separate files, but eventually we can live 
> with how adun works right now.
> 
> The "initial" coordinates are in the datasource to store all information on a 
> system in one file - so one PDB -> one datasource. This makes many storage 
> and other operations simpler. However you don't have to use the coordinates 
> in the datasource (the linking we discuss) and you can replace the 
> coordinates in it with others. If necessary we can add further ways to set 
> initial coordinates. 
> 
> Also remember the datasource class, and Adun, has been designed to support 
> reactivity from the start - some of the things that are different between it 
> and other packages are because of this. 
>  
> The SCAAS should be applied automatically to any generated or read 
> water+protein system, according to the rules above.
> 
> In the medium term, it appears obvious to me to segregate topology from 
> coordinates in two separate files. This will help a lot in many issues.
> 
> On Jan 19, 2012, at 3:36 PM, Michael Johnston wrote:
> 
>> Unfortunately making it automagic essentially is the same as Nils's 
>> suggestion where I had problems previously.
>> 
>> The only requirement the linking has as it stands is you use the same input 
>> protein datasource for each run (and the same container dimensions of 
>> course) when there is water you also want to link - it seems minimal. The 
>> way I was thinking this would work is that you would just change e.g. the 
>> minimisation template, to remove the minmiser and add the simulator. Then it 
>> will just work.
>> 
>> I will recheck doing it the way Nils suggested - perhaps the problems are no 
>> more.
>> One potential issue I see with taking the datasources directly from another 
>> simulation is that you may create a completely different system then you 
>> intended in the template (because you just replace, without checking, 
>> datasources based on names). There would also be a problem in the case where 
>> the topology of the system was being modified in the previous simulation 
>> (and you didn't want the topology modifications).
>> 
>> If it is possible to do I will add a flag like -ReplaceAll which would 
>> control which method was used.
>> 
>> 2012/1/19 Jordi Villà i Freixa <[EMAIL PROTECTED]>
>> 
>> On Jan 19, 2012, at 2:54 PM, Michael Johnston wrote:
>> 
>> > On Thu, Jan 19, 2012 at 11:13 AM, Nils Jan Daniel Drechsel <
>> > [EMAIL PROTECTED]> wrote:
>> >
>> >> Hi Michael,
>> >>
>> >> one question: Wouldn't it be possible to directly copy the systems from
>> >> one simulation to the other simulation when the simulations are linked and
>> >> systems with the same name can be found in the two of them instead of
>> >> rebuilding the systems and copying the coordinates and velocities?
>> >>
>> >
>> > This is actually the way I tried first, but there appeared some subtle
>> > problem that I can't remember of the top of my head. The way its done now
>> > was the alternative which I switched to as it had no issues and was very
>> > quick to implement.
>> >
>> >
>> >> Otherwise I guess there will always be a problem with the water container,
>> >> since the amount of water molecules depends on the protein volume which 
>> >> can
>> >> change between simulations.
>> >>
>> >
>> > Yes it can in general, but the linking should use the *same* initial
>> > protein configuration as the input to both configurations (in the case
>> > where you want to link the container that is) so this shouldn't be an issue
>> > for it.
>> >
>> > That is the initial systems built in the first and second runs should be
>> > identical as far as the number of solvent molecules goes. Then all you do
>> > is change the initial coordinates/velocities of the second run to those in
>> > frame X of the first run to start from that point.
>> 
>> that seems like an excellent solution and not at all unelegant. However, 
>> this should be done automagically in the program (regarding your next 
>> sentence). Can this be set up?
>> 
>> >
>> > Perhaps this is the problem - is the simulation being started from the same
>> > conditions as the minimisation?
>> >
>> >
>> >>
>> >> On Thu, Jan 19, 2012 at 10:23 AM, Michael Johnston <
>> >> [EMAIL PROTECTED]> wrote:
>> >>
>> >>> This is the same error as previous -
>> >>>
>> >>> 2012-01-18 20:13:46.958 AdunCore[7501] Error code 13
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Description - Unable to set
>> >>>> coordinates for H2OContainer using link
>> >>>> *2012-01-18 20:13:46.958 AdunCore[7501] Detail - The two systems do not
>> >>>> **contain the same number of elements*
>> >>>
>> >>>
>> >>>
>> >>> Check the entry for HOH-Container in the Minimisation log and this log
>> >>> for
>> >>> descrepencies
>> >>>
>> >>> On Wed, Jan 18, 2012 at 7:36 PM, deepak kumar <[EMAIL PROTECTED]
>> >>>> wrote:
>> >>>
>> >>>> I tried to run the simulation. Minimization went fine, but got this
>> >>> error.
>> >>>>
>> >>>>
>> >>>> AdunCore.log file looks like this :
>> >>>>
>> >>>> Linking from simulation at SimulationOutput/Minimisation1.simulation
>> >>>>       No trajectory specified - defaulting to active
>> >>>>       This is at
>> >>>>
>> >>>>
>> >>> file:/cbbl/users/deepak/simulations/mac_2kxn_with_RNA_maestro_without_minimization/SimulationOutput/Minimisation1.simulation/Trajectory0/
>> >>>>       Systems to link not specified - defaulting to all: H2OContainer,
>> >>>> 2kxnB_maestroreduce_xleap_fixed
>> >>>>       Linking to last checkpoint (1001)
>> >>>>       Linked coordinates of system 2kxnB_maestroreduce_xleap_fixed
>> >>>>       Linked velocities of system 2kxnB_maestroreduce_xleap_fixed
>> >>>>       Unable to link system H2OContainer. See error log.
>> >>>>
>> >>>> AdunCore.errors file looks like this :
>> >>>>
>> >>>> 2012-01-18 20:13:44.581 AdunCore[7501] Force field Amber99SB
>> >>>> 2012-01-18 20:13:44.717 AdunCore[7501] Force field Amber99SB
>> >>>> 2012-01-18 20:13:44.940 AdunCore[7501] Force field GAFF
>> >>>> 2012-01-18 20:13:45.343 AdunCore[7501] Stored URL is
>> >>>>
>> >>>>
>> >>> file://localhost/cbbl/users/deepak/simulations/mac_2kxn_with_RNA_maestro_without_minimization/SimulationOutput/Minimisation1.simulation/
>> >>>> GSCBufferString
>> >>>> 2012-01-18 20:13:45.343 AdunCore[7501] Decode data URL
>> >>>>
>> >>>>
>> >>> file://localhost/cbbl/users/deepak/simulations/mac_2kxn_with_RNA_maestro_without_minimization/SimulationOutput/Minimisation1.simulation/
>> >>>> and path
>> >>>>
>> >>>>
>> >>> /cbbl/users/deepak/simulations/mac_2kxn_with_RNA_maestro_without_minimization/SimulationOutput/Minimisation1.simulation/
>> >>>> 2012-01-18 20:13:46.719 AdunCore[7501] Replaced coordinates of system
>> >>>> 2kxnB_maestroreduce_xleap_fixed with those from link
>> >>>> 2012-01-18 20:13:46.726 AdunCore[7501] Replaced velocties of system
>> >>>> 2kxnB_maestroreduce_xleap_fixed with those from link
>> >>>> 2012-01-18 20:13:46.957 AdunCore[7501] Unable to set coordinates for
>> >>>> H2OContainer using link
>> >>>> 2012-01-18 20:13:46.957 AdunCore[7501] Incompatible number of elements
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Detected error at top level -
>> >>>> Simulation exiting
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Error details follow
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Logging error from domain
>> >>>> AdunCore.ErrorDomain
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Error code 13
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Description - Unable to set
>> >>>> coordinates for H2OContainer using link
>> >>>> 2012-01-18 20:13:46.958 AdunCore[7501] Detail - The two systems do not
>> >>>> contain the same number of elements
>> >>>> Processing link {simulation =
>> >>> SimulationOutput/Minimisation1.simulation; }
>> >>>> ~
>> >>>>
>> >>>> ~
>> >>>>
>> >>>> ~
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Deepak Kumar
>> >>>>
>> >>>> This message has been automatically forwarded to you by the Adun team
>> >>>> http://adun.imim.es
>> >>>> _______________________________________________
>> >>>> Adun-users mailing list
>> >>>> [EMAIL PROTECTED]
>> >>>> https://mail.gna.org/listinfo/adun-users
>> >>>>
>> >>>
>> >>> This message has been automatically forwarded to you by the Adun team
>> >>> http://adun.imim.es
>> >>> _______________________________________________
>> >>> Adun-users mailing list
>> >>> [EMAIL PROTECTED]
>> >>> https://mail.gna.org/listinfo/adun-users
>> >>>
>> >>
>> >>
>> >
>> > This message has been automatically forwarded to you by the Adun team 
>> > http://adun.imim.es
>> > _______________________________________________
>> > Adun-users mailing list
>> > [EMAIL PROTECTED]
>> > https://mail.gna.org/listinfo/adun-users
>> 
>> --
>> Jordi Villà i Freixa
>> Computational Biochemistry and Biophysics lab
>> Research Group on Biomedical Informatics (GRIB) - IMIM/UPF
>> Parc de Recerca Biomèdica de Barcelona
>> C/ Doctor Aiguader, 88; 08003 Barcelona (Spain)
>> Tel: +34 93 316 0504 // Fax: +34 93 316 0550
>> e-mail: [EMAIL PROTECTED]
>> http://cbbl.imim.es
>> 
>> 
> 
> -- 
> Jordi Villà i Freixa
> Computational Biochemistry and Biophysics lab
> Research Group on Biomedical Informatics (GRIB) - IMIM/UPF
> Parc de Recerca Biomèdica de Barcelona
> C/ Doctor Aiguader, 88; 08003 Barcelona (Spain)
> Tel: +34 93 316 0504 // Fax: +34 93 316 0550
> e-mail: [EMAIL PROTECTED]
> http://cbbl.imim.es
> 
> 

-- 
Jordi Villà i Freixa
Computational Biochemistry and Biophysics lab
Research Group on Biomedical Informatics (GRIB) - IMIM/UPF
Parc de Recerca Biomèdica de Barcelona
C/ Doctor Aiguader, 88; 08003 Barcelona (Spain)
Tel: +34 93 316 0504 // Fax: +34 93 316 0550
e-mail: [EMAIL PROTECTED]
http://cbbl.imim.es


This message has been automatically forwarded to you by the Adun team 
http://adun.imim.es
_______________________________________________
Adun-users mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/adun-users