From: Ola S. <ola...@fa...> - 2005-01-17 10:14:36
|
Hello, I would like to propose the use of a config file instead of having parameter files (e.g. "data/mm2.prm") hardcoded into CDK. Regards, .../Ola Spjuth |
From: Egon W. <e.w...@sc...> - 2005-01-17 10:43:29
|
On Monday 17 January 2005 11:16 am, Ola Spjuth wrote: > I would like to propose the use of a config file instead of having > parameter files (e.g. "data/mm2.prm") hardcoded into CDK. This deals with force fields, correct? Can you give some more details? Egon |
From: Ola S. <ola...@fa...> - 2005-01-17 12:28:39
|
Well, nothing much. I just would like to be able to edit configuration of additional parameters in a config-file at runtime. Now I have to recompile CDK every time I change the names and location of, for example, parameter files (such as for force fields, but this is just an example). If you don't like this idea then I guess I have to modify CDK every time I update from CVS, but I am lazy and think that these parameters should be available at runtime. .../Ola On Mon, 2005-01-17 at 11:42, Egon Willighagen wrote: > On Monday 17 January 2005 11:16 am, Ola Spjuth wrote: > > I would like to propose the use of a config file instead of having > > parameter files (e.g. "data/mm2.prm") hardcoded into CDK. > > This deals with force fields, correct? Can you give some more details? > > Egon |
From: Egon W. <e.w...@sc...> - 2005-01-17 13:04:49
|
On Monday 17 January 2005 01:30 pm, Ola Spjuth wrote: > Well, nothing much. I just would like to be able to edit configuration > of additional parameters in a config-file at runtime. Now I have to > recompile CDK every time That's not nice indeed... > I change the names and location of, for > example, parameter files (such as for force fields, but this is just an > example). > If you don't like this idea I do like the idea... just wanted to make sure where things would need to be changed... :) > then I guess I have to modify CDK every time > I update from CVS, but I am lazy and think that these parameters should > be available at runtime. |
From: Ola S. <ola...@fa...> - 2005-01-17 14:12:12
|
Egon, Well, here are some proposals on parameters I believe should be in a config-file to be read at runtime. Maybe some aren't very useful to change, but others most definitely are (at least for me). LoggingTool: "org/openscience/cdk/config/data/log4j.properties" MMFF94BasedParameterSetReader: private String configFile = "mmff94.prm"; MM2BasedParameterSetReader: Private String configFile = "mm2.prm"; ForceFieldConfigurator.setForceFieldConfigurator...{ ... this.getClass().getClassLoader().getResourceAsStream("/home/ola/workspace/se.uu.farmbio.procmis/data/mm2.prm"); ... this.getClass().getClassLoader().getResourceAsStream("/home/ola/workspace/se.uu.farmbio.procmis/data/mmff94.prm"); ... } CDKBasedAtomTypeConfigurator: private String configFile = "org.openscience.cdk.config.data.structgen_atomtypes.xml"; IsotopeFactory: String configFile = "org/openscience/cdk/config/data/isotopes.xml"; TXTBasedAtomTypeConfigurator: private String configFile = "jmol_atomtypes.txt"; These are just examples of files I would like to be able to edit the content and location of at runtime. There are probably more that I have forgotten. Cheers, .../Ola On Mon, 2005-01-17 at 14:04, Egon Willighagen wrote: > On Monday 17 January 2005 01:30 pm, Ola Spjuth wrote: > > Well, nothing much. I just would like to be able to edit configuration > > of additional parameters in a config-file at runtime. Now I have to > > recompile CDK every time > > That's not nice indeed... > > > I change the names and location of, for > > example, parameter files (such as for force fields, but this is just an > > example). > > If you don't like this idea > > I do like the idea... just wanted to make sure where things would need to be > changed... :) > > > then I guess I have to modify CDK every time > > I update from CVS, but I am lazy and think that these parameters should > > be available at runtime. |
From: Egon W. <e.w...@sc...> - 2005-01-17 16:18:54
|
On Monday 17 January 2005 03:14 pm, Ola Spjuth wrote: > Well, here are some proposals on parameters I believe should be in a > config-file to be read at runtime. Maybe some aren't very useful to > change, but others most definitely are (at least for me). Excellent! This the type of details I was hoping for. > LoggingTool: > "org/openscience/cdk/config/data/log4j.properties" I know that people in the past used customized Log4J properties... and at some point the constructure was modified for such reasons, but yes, this should be customizable... > MMFF94BasedParameterSetReader: > private String configFile = "mmff94.prm"; > > MM2BasedParameterSetReader: > Private String configFile = "mm2.prm"; > > ForceFieldConfigurator.setForceFieldConfigurator...{ > ... > this.getClass().getClassLoader().getResourceAsStream("/home/ola/workspace/ >se.uu.farmbio.procmis/data/mm2.prm"); ... > this.getClass().getClassLoader().getResourceAsStream("/home/ola/workspace/ >se.uu.farmbio.procmis/data/mmff94.prm"); ... > } That would be useful too. > CDKBasedAtomTypeConfigurator: > private String configFile = > "org.openscience.cdk.config.data.structgen_atomtypes.xml"; > > IsotopeFactory: > String configFile = "org/openscience/cdk/config/data/isotopes.xml"; > > TXTBasedAtomTypeConfigurator: > private String configFile = "jmol_atomtypes.txt"; The AtomType- and IsotopeFactory can already use custom configuration files. I guess, however, what you want to do here, is have certain algorithms use changed versions of the tables. Is that correct? Are the tables in CVS not good? Other than with force fields, I see no direct use why to change these on runtime... atom type and isotope tables should be rather fixed... i.e. there is only one type of physical isotope properties, and only one type of PDB atom types... > These are just examples of files I would like to be able to edit the > content and location of at runtime. There are probably more that I have > forgotten. Making them customizable is not that difficult... but I want to make sure we get the API correct... Egon |
From: Egon W. <e.w...@sc...> - 2005-02-03 21:07:24
Attachments:
result.txt
|
On Tuesday 18 January 2005 16:04, Martin Eklund wrote: > A while ago I talked about changing the PDBReader and the way CDK > handles multistranded proteins. I've had so much to do that I haven't > got around to do those changes until now... Anyway, I attach the source > files. You are of course most welcome to use it if you want to. In general all patches look fine, so I've applied them to CDK CVS. Sorry that I forgot to do it. Too busy, and thanx for reminding me. There are a number of issues though... as you will have seen is that the data module is now 'stable', but the patches lack testing method in PolymerTest and StrandTest (see attached result.txt, made with ant clean test-all)... we should get this fixed before the next release, around march 1st... Also two PDB reading tests fail, which might be related to (?): > One problem with the way I've done it is if a PDB file actually contains > more than one molecule. The file then has to be modified before it is > read, otherwise it will be regarded as one molecule. Please explain. We'll have to fix this too. I'll go on holiday on saturday, but will try to read my email tomorrow... Egon -- e.w...@sc... PhD student on Molecular Representation in Chemometrics Radboud University Nijmegen http://www.cac.science.ru.nl/people/egonw/ GPG: 1024D/D6336BA6 |