unicorn team mailing list archive

[Niclas Jansson <njansson@xxxxxxxxxx>]

Johan Jansson <jjan@xxxxxxxxxx> writes:

> We've discussed the Unicorn end-user interface off-list, I'm pasting a
> summary of the discussion below:
>
> ---
>>Johan Jansson <jjan@xxxxxxxxxx> writes:
>>> On Tue, Jun 28, 2011 at 3:21 PM, Niclas Jansson <njansson@xxxxxxxxxx> wrote:
>>>> Johan Jansson <jjan@xxxxxxxxxx> writes:
>>>>
>>>> Hi,
>>>>
>>>>> To represent structure geometry in fluid-structure interaction
>>>>> problems we use a DOLFIN mesh in Unicorn. We thus need to add an
>>>>> argument to the solve() function, so the signature looks like:
>>>>>
>>>>> void solve(Mesh& mesh, Checkpoint& chkp, long& w_limit, timeval&
>>>>> s_time, Mesh* structure_mesh)
>>>>>
>>>>> where structure_mesh is 0 for a pure fluid problem.
>>>>>
>>>>> Any comments on the interface are welcome. If the argument list grows
>>>>> even more (perhaps a geometry object for the boundary, etc.), an
>>>>> alternative design could be to specify file names in the parameter
>>>>> file.
>>>>>
>>>>> Best,
>>>>>   Johan
>>>>
>>>> Another options is to use a variable argument list for the meshes
>>>> (stdarg.h), something like
>>>>
>>>> void solve(Mesh& mesh, Checkpoint& chkp,
>>>>     long& w_limit, timeval& s_time, Mesh *aux_mesh, ...)  {
>>>>     va_list list;
>>>>     va_start(list, aux_mesh);
>>>>
>>>>     /*  Extract meshes from aux_mesh, and add them to the solver */
>>>>
>>>> }
>>>>
>>>> Yet another option is to give the meshes as extra arguments at startup,
>>>>
>>>> ./apa -p parameters -m mesh -sm struct_mesh -g geometry ... etc..
>>>>
>>>> Niclas
>>>>
>>>
>>> Yes, this is how it would look now, with passing the extra arguments
>>> on the command line. I think it works well (as long as there aren't
>>> too many arguments). Varargs is an option for handling the signature,
>>> but don't you think it would reduce the readability? Perhaps to use a
>>> dictionary/map (such as the DOLFIN parameter system) would be enough
>>> for this purpose?
>>>
>>> But for now, with only 2 mesh/geometry arguments, I think it's enough
>>> to just use a standard argument list.
>>>
>>> Best,
>>>   Johan
>>
>>
>>Agree, varargs produces slightly unreadable code. But I'm not sure whats
>>best, give these filenames on the command line or through the parameter
>>file.
>>
>>Personally I would like to keep the necessary arguments for unicorn_init
>>as short as possible, it's less error prone. If we pass everything on
>>the command line, we also have to figure out which combinations are
>>valid, for example if a users gives an structure mesh but not a mesh.
> ...
>> Niclas
> ---
>
> I think all of the filenames can be defined in the parameter file,
> since they define the problem to be solved. If we write the parameter
> file in XML we can define restrictions on the input (for example that
> there must be a mesh defined) in a simple way with XML Schema, which
> can be validated with for example the tool xmllint. I also think the
> argument list for unicorn_init() should be short, and also the number
> of command-line arguments, which should only have to do with how to
> run the job (i.e. name of parameter file, restart checkpoint,
> MPI/OpenMP, etc.).
>
> Best,
>   Johan
>

Sounds good, I like the idea of having everything in the parameter
file. But I'm not a big fan of xml, sure it's robust and nice but it
was truly painful to cross compile on the cray.

Can't we use the existing parameter system, and throw and error if for
example a mesh filename ain't specified.

Niclas