WIP: postProcess: handle errors reading constantObjects

Addresses #539 (closed).

This is probably not a good solution, but it does resolve the issues I was having. Ideally, selectedFields would be used to only attempt to read fields named accordingly. Perhaps IOobjectsList could accept a list of names in a constructor.

Is the test application for IOobjectsList considered a good check for any broken functionality?

I agree that the try/catch isn't really the way to go. Rather than a list of names, a ioobjlist constructor taking a unary predicate would be the totally flexible way to go. The HashSet (reworked for 1706) has a operator() that lets it be used as predicate directly, we could pass through a lambda. I guess that the predicate would need to be the first or second constructor parameter. Would you be willing to give this a try? Several of us are in Exeter next week, so won't be able to do much anyhow... plus it might be an interesting exercise for you too? Add a templates file for ioobjectlist, breakout some of the matcher bits from the .C file and bump them into the constructor. You'll also notice we have a predicates::always util if it is worth doing a total refactor.

Nonetheless I would like to take a closer look to see what is currently going wrong. Although, if I had a similar set of templates, I would probably have placed them in a parallel set of directories anyhow. Eg, templates/constant/turbulenceProperties, templates/system/blockMeshDict, etc.

I am willing to take a stab at modifying the constructor, but it will take me a little bit--busy with quite a few projects at the moment.

Your suggestion to use a separate templates directory is coincidentally where I'm moving towards. Currently, with the template file in constant, the failure occurs here:

FoamFile
{{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      turbulenceProperties;
}}

Braces in templates are doubled up in order to use Python's new style string formatting. Nonetheless, I am going to switch to a using templates directory, but a more robust solution for postProcess reading objects in constant can't be a bad thing.

By Pete Bachant on 2017-07-22T14:15:50 (imported from GitLab project)

Hi Pete, there isn't going to be much that we can do to handle that type of content. If the doubled braces occurred later, it might be possible to avoid. But since your FoamFile entry itself has these doubled braces, it will result in a bad parse in the header. Extra rules to handle doubled braces etc would be messy, likely fragile, or badly behaved. I think that this just needs to categorized as "don't use that sort of input". Everything else is just getting too strange.

Nonetheless, maybe there is something to be done with backslash escaping ... provided that it helps from the python-side. BTW, since you've been working on this sort of thing, have you had any ideas about an OpenFOAM customized meta-processor? This is something that I've thought a little bit about - it would be nice to replace our use of m4 (especially for windows users).

Not a problem. I wouldn't suggest changing dictionary parsing rules to accommodate my own weird formatting. I think simply having postProcess respect the field or fields argument would fix this and probably save a little overhead. It shouldn't be loading turbulenceProperties anyway unless called from a solver, right?

In my opinion, a major game-changer for OpenFOAM manipulation and automation would be the implementation of a FoamDictionary as a Python object, which I have done a tiny bit of work on, and really need to get back to: https://github.com/petebachant/foamPy/issues/26

By Pete Bachant on 2017-07-23T15:09:43 (imported from GitLab project)

There probably isn't much performance gain if the fields are prefiltered in IOobjectList. We'd still obtain a list of filenames, creating the IOobject itself is fairly low overhead. The first bit of real IO is when the header type is checked (incidently also what is causing your failure), but this itself is fairly low overhead - just parsing the FoamFile subdict, but not the entire file. This would actually this place to fit your try/catch. If the header read fails, could emit a warning and then drop the object. Note that the turbulenceProperties aren't actually being loaded as part of turbulence or anything, it is just being caught in the general equivalent of an ”ls”, which is how the IOobject list is functioning at the point.

Going to close this and work on making IOobjectList fail more gracefully.

By Pete Bachant on 2017-07-27T23:49:14 (imported from GitLab project)

closed

By Pete Bachant on 2017-07-27T23:49:14 (imported from GitLab project)