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
<[email protected]<mailto:[email protected]>> 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
