I would suggest that we look at several quantum chemistry applications which have slight variations on the theme. We have NWChem, Gamess, and Molpro examples to look at. I can send some input files and/or have a session to go over the relevant sections. We can do this later today.
Thanks, Sudhakar. On Dec 8, 2014, at 10:23 AM, Marlon Pierce <marpi...@iu.edu> wrote: > The more examples, the better. I'd like to find the right balance between > understanding the problem space and making incremental progress. > > Marlon > > On 12/8/14, 10:38 AM, Pamidighantam, Sudhakar V wrote: >> Chaturi: >> Thanks for these suggestions. One question I have is whether we should look >> at some of the input files in the set of applications currently under >> testing to come up with these requirements. >> There may be additional requirements in some of the inputs. Of course we can >> incrementally update the data structures as well as we test these >> applications in more depth. But I feel some significant number of >> application cases should be accommodated with each update. We may target >> these for rc 0.15 and depending on the time available we can look at at >> least few more applications. >> >> Comments? >> >> Thanks, >> Sudhakar. >> On Dec 8, 2014, at 9:22 AM, Chathuri Wimalasena >> <kamalas...@gmail.com<mailto:kamalas...@gmail.com>> wrote: >> >> Hi Devs, >> >> We are trying to add Gaussian application using airavata-appcatalog. While >> doing that, we face some limitations of the current design. >> >> In Gaussian there are several input files, some input files should used when >> the job run command is generated, but some does not. Those which are not >> involved with job run command also need to be staged to working directory. >> Such flags are not supported in current design. >> >> Another interesting feature that in Gaussian is, in input file, we can >> specify the values for memory, cpu like options. If input file includes >> those parameters, we need to give priority to those values instead of the >> values specified in the request. >> >> To support these features, we need to slightly modify our thrift IDLS, >> specially to InputDataObjectType struct. >> >> Current struct is below. >> >> struct InputDataObjectType { >> 1: required string name, >> 2: optional string value, >> 3: optional DataType type, >> 4: optional string applicationArgument, >> 5: optional bool standardInput = 0, >> 6: optional string userFriendlyDescription, >> 7: optional string metaData >> } >> >> In order to support 1st requirement, we introduce 2 enums. >> >> enum InputValidityType{ >> REQUIRED, >> OPTIONAL >> } >> >> enum CommandLineType{ >> INCLUSIVE, >> EXCLUSIVE >> } >> >> Please excuse me for names. You are welcome to suggest better names. >> >> To support 2nd requirement, we change metaData field to a map with another >> enum where we define all the metadata types that can have. >> >> enum InputMetadataType { >> MEMORY, >> CPU >> } >> >> So the new InputDataObjectType would be as below. >> >> struct InputDataObjectType { >> 1: required string name, >> 2: optional string value, >> 3: optional DataType type, >> 4: optional string applicationArgument, >> 5: optional bool standardInput = 0, >> 6: optional string userFriendlyDescription, >> 7: optional map<InputMetadataType, string> metaData, >> 8: optional InputValidityType inputValid; >> 9: optional CommandLineType addedToCommandLine; >> 10: optional bool dataStaged = 0; >> } >> >> Suggestions are welcome. >> >> Thanks, >> Chathuri >> >> >> >
