Description of feature

There should be a way (via inheritance) to access and store the version of the inherited class instance. This can then be used in printing to make clear what version of the specific solver is.

Description of feature

There are two cases where we can do better

• There are times where an option takes in a list of acceptable values. Example here. Realistically, this should be a set and we check for subset membership with passed in options. If the order matters (say for printing the monitor values) we can sort them and convert to list after parsing the options
• Some options take in an object which can be either a single string or a list of strings. Example here. The easiest thing to do would be to force it to be a list, so the user must wrap single strings as a list. Or we can do some sort of fancier data typing if we want.

Description

Say you have a dictionary in the reference file, and use root_add_dict for training/testing. If the reference dictionary is a superset of the dictionary generated from testing, then the test is considered to pass, since we just loop over the generated dictionary keys, rather than the reference dictionary keys.

Steps to reproduce issue

Imagine if the reference JSON file contained the following dictionary

{'a':1, 'b':2, 'c':3}

and the dictionary generated by the test is

{'a':1, 'b':2}

Current behavior

root_add_dict will consider the test to be successful.

Expected behavior

The test should fail.

Description

Now that we are all using Python 3, I don't think this is needed anymore. However, I want to know the motivation for this since ADflow is currently using this. Can I just remove the call in there? Perhaps @JustinSGray knows?

Description of feature

We don't have any explanation for people who want to write tests and use BaseRegTest.

Potential solution

Example usage can be found in many of our repos, such as pyGeo and IDWarp. Complex use cases involving inherited test classes (e.g. ADflow) should also be mentioned.

Description of feature

Often if you want to be able to read the iteration printout of the pyAeroStructure MDA you have to suppress the iteration printing of the aero and structural solvers which can make it hard to diagnose problems. To help with this we should implement the ability to redirect the output from the 3 different solvers to 3 different files.

Previously, I implemented this in pyAeroStructure using multipoint's redirectIO method, but it was bespoke and not extensible to other combinations of solvers. You can see the implementation here

Potential solution

Instead we should add redirectIO functionality to our 3 solver types so they each can take a stdoutFile argument.

We should aim to implement something like _setSTDOut in the BaseSolver class so it can be inherited by each solver and then add in calls to it in the right places (e.g in __call__, evalFunctions etc) in each solver.

Description

The CaseInsensitive containers are not properly formatted when printed with pprint. This bug was introduced with the ABC implementation in #51. I realized this because the ADflow options dictionary is now printed in one massive line instead of having line breaks. The same bug applies to both CaseInsensitiveDict and CaseInsensitiveSet.

Steps to reproduce issue

Here is a MWE for CaseInsensitiveDict:

from baseclasses.utils import CaseInsensitiveDict
from pprint import pprint

sensitive = {"b-longstring": 2, "a-longstring": 1, "c-longstring": 3, "e-longstring": 5, "d-longstring": 4}
insensitive = CaseInsensitiveDict(sensitive)

pprint(sensitive)
pprint(insensitive)

Current behavior

>>> pprint(sensitive)
{'a-longstring': 1,
 'b-longstring': 2,
 'c-longstring': 3,
 'd-longstring': 4,
 'e-longstring': 5}

>>> pprint(insensitive)
{'b-longstring': 2, 'a-longstring': 1, 'c-longstring': 3, 'e-longstring': 5, 'd-longstring': 4}

Expected behavior

>>> pprint(sensitive)
{'a-longstring': 1,
 'b-longstring': 2,
 'c-longstring': 3,
 'd-longstring': 4,
 'e-longstring': 5}

>>> pprint(insensitive)
{'a-longstring': 1,
 'b-longstring': 2,
 'c-longstring': 3,
 'd-longstring': 4,
 'e-longstring': 5}

Description

This repo barely has any tests. Some classes are well tested while others have zero tests whatsoever. In particular, more unit tests would be welcome. For reference, our test coverage is only 26%.

Description

Currently, keys are cast to lower case on initialization and subsequent addition. We can instead keep those as they are, and just change the string comparison so that they are case insensitive. We should do the same thing for sets also.

Description of feature

Come up with a way during solver initialization to specify combination of options which are incompatible with each other.

Potential solution

In order to make this general, maybe use a tuple approach?

incompatibleOptions = [({"option1": "value1"}, {"option2": "value2"}), ...]

Description of feature

Similar to the reasoning presented in mdolab/pygeo#85. It would be useful to import BaseSolver without importing mpi4py. The problem occurs in the __init__.py where BaseRegTest is imported. The no-mpi branch removes the problematic line

Potential solution

This is a backward compatibility breaking change, but a potential fix is to remove the import BaseRegTest from the __init__.py

Description of feature

Similar to the list of choices, we should also allow for sets. This would be useful for things like monitorVariables in ADflow, where we want the default options to list out all the possible values. The user options would then be checked that it is a subset of the full set. This would also allow for a description of each value in the options table.

One question is whether these values should be ordered. For safety under parallel execution, we probably want to cast the final set (after error checking) into a sorted list, in case the solvers expect a list to iterate over.

Description

For pretty much all the repos, we just promote all classes (and some functions too) to the top level using the root __init__ file. This "flat" structure works fine for simple repos, i.e. those with a single python wrapper file (IDwarp, pyHyp, etc.). But for more complex packages I think we should probably change this and create submodules, i.e. subdirectories with __init__ files in them.

However, if we do this we probably want to reorganize the __init__ files a bit. I see several approaches:

1. leave __init__ files empty, and explicitly import everything using the "full" path. Pro: very explicit. Con: very verbose/redundant
2. identify things that we want to be accessible, and include those in the __init__ file of the directory that contains the object. Pro: imports are nicer (from baseclasses.solvers import BaseSolver). Con: have to decide what to promote, effectively designing the API.
3. use an API file (c.f. OpenMDAO). Pro: can now move stuff in the future without worrying about user-facing imports. Con: still have to decide what goes in here, but also somewhat a bigger change.

I am personally in favour of 2) but happy to have a discussion on this. Regardless, this will break backwards compatibility so we have to be careful. There are probably other repos out there that could benefit from this type of reorganization.

Questions:

• Are we okay with breaking backwards compatibility? Is there a way to ensure smooth transition by temporarily supporting both old and new API?
• Do we think the proposed submodule approach is useful?
• How do we want to set up the init files?

Description

Andrew from AERO740 found that when xref, not xRef is passed into AeroProblem(), the initialization is just fine even though nothing is happening.
I think baseclasses should return an error.

1. This could be modifying the AeroProblem python code to check a list of all supported keyword arguments. Return an error if the supplied arg does not exist in the supported keyword arguments.
2. Another method could be changing the function signature of the __init__() to list out all the kwargs.

I am open to hearing other approaches too.

Steps to reproduce issue

Something like
ap = AeroProblem(args=args, unsupportedArg=randomValue)
or rather
ap = AeroProblem(xref=0.5) does not return an error that you're not setting xRef as intended

Current behavior

…
Does not throw an error for unsupported keyword arguments in AeroProblem instantiation.

Expected behavior

…
Throw an error for unsupported keyword argument

Code versions

• Operating System:
• Python:
• OpenMPI:
• CGNS:
• PETSc:
• Compiler:
• This repository:

Description of feature

We should have a general way of handling option changes after instantiation

• keep track with flags
• after they change, __call__ or equivalent should print the new modified options