nerisaurus
commented
8 years ago Closing issue due to the 2D refactoring efforts. This may still be a useful resource at points to try to understand how good the previous inputs were to a problem (and whether they might be the cause of an error found in the new refactored test), but is not really as relevant to the current set of tests that are being developed.
Overview A vaguely comprehensive list of models in air-water-vv/2d/ which I am unable to run or which otherwise don't work smoothly and intuitively. See #107 for an analogous list of issues in the 3d models.
If a model isn't listed, it at least starts up without a noticeable error, so I have not yet identified an issue with it. Not all have been run to completion due to computational time and the occasional memory problem (which is not necessarily a failure of the model). Models that are checked off indicate that I have a known fix which when applied makes them run cleanly (they run to completion, don't run into other issues, and the fix isn't just a hack).
If you also notice a problem, see if it fits in the categories below and see if the fixes or information supplied there can help. Otherwise:
Miscellaneous Problems Issues where several models appeared to fail in the same way or which were particularly noteworthy are listed in their own sections below. These models had more unique problems. They are usually due to missing or obsolete references to files, modules, functions, and function arguments. Some may be due to accidental removal (or rather, non-inclusion) of files with the repository. Some are just due to changes in Proteus.
The inputs do not match how the Proteus LineGauges worked at any point in git recorded history, but do match some of the independent LineGauges classes that are floating around in some of the other tests (e.g. broad_crested_weir_AV)- so it probably pre-dates the official Proteus implementation (although it was brought in to a commit referencing Proteus already, so I'm not sure how that worked).
It's unclear to me what the line gauges intention was, since for the style of input its giving a lot of information was baked into the free-form LineGauge classes (which are not recorded in git history). It shouldn't be too hard to set the line gauges up with the newer standard, but picking what they record and when might be arbitrary unless anyone has input on that.
This used to be an input for proteus/proteus/mprans/MoveMesh.py 's Coefficients. However, in August/September last year that file got cleaned up and that functionality was removed. I'll look into how to adapt it to the new framework if nobody else happens to recall what to do in such a case.
epsFact_solidvalue that is a float rather than an array. Crashes as a result.This module doesn't seem to be used by moving_cylinder.py or anything directly attached to it, and the program begins to run smoothly with the import of symmetricDomain_john just cut out.
It has an issue running in parallel, throwing up the
warning before crashing due to:
This only occurs in parallel runs during my tests.
wavetank_generic This model has its own section because it has a series of interesting problems.
print amplitude.transectShort.txttransect.txttransectVeryShortAndShallow.txttransectVeryShort.txtand that 'transectBox.txt' may have been intended to be a placeholder for a more general case, or for another similar file that wasn't included in the repository.
Parallel Issues _These methods can run serially, but in parallel they throw up
AttributeError: LevelModel instance has no attribute 'owned_local'in a NonlinearSolvers step. This may be recent behavior, because I've normally run these serially due to their small size and lack of noticeable speedup._With No Boundary Condition Set These methods spit out a lot of repetitive warning messages, but do not crash. The warning given is of the form:
_The warnings may need to be handled more cleanly, to avoid flooding the output as much, if the warnings are not in themselves fatal. The warnings may cause the erratic performance behavior (unusual CPU use that appears to start and stop a lot) in both tests, although that could also be due to other related problems (broad_crested_weir has a solver related failure as noted below, and sharp_crested_weir_VMV1 may have a similar issue - but has not been run long enough to check that yet).
warning: VOF open boundary with no external trace, setting to zero for inflowfor similar reasons in asimilar fashion) with vof_p.py as well.This (both navier stokes and vof issues) may be fixed by ad-hoc adjustments to the boundary conditions given, including reverting to the older boundary conditions that are stored in some older files. The rhyme and reason of the conditions which need to be changed is a bit obscure for me, but it appears an issue with the boundary setup rather than a technical mistake.
If this doesn't fix itself in a rebuilding of the boundary conditions from basic principles and the Proteus/mprans BoundaryConditions.py, the ad-hoc fix might be the way to go - it doesn't seem to change much in terms of outputs, although its setup may be refined a bit.
redist_p.pyls_consrv_p.py(possibly with 2 to 4 separate triggers - the log at level 10 doesn't have enough distinction to be confident about how I'm parsing this)twp_navier_stokes_p.py(possibly with multiple triggers, although the extra distinct warnings types might be due instead to race conditions on printing results)Gauge Segmenting Problems These methods use Proteus' Gauges and run into an error where the Gauges appear to be unable to figure out where to put the gauges in the mesh. The error that commonly comes up goes like:
This issue can also be noticed because the file will dump a large set of array data (and some other data - but the array data is most noticeable) before failing - this is part of the gauge tools method for dealing with this error. After bringing up the error, the program will sit indefinitely until forced closed.
This typically applies to only particular gauges (or rather, lines of gauges) - when these gauges are removed from consideration, the program will run without (this) issue (it will still have other problems if there are other errors). Changes to Gauge logic (as in erdc-cm/proteus#404 ) or to the segments and vertices of the problem, may also cause the problem to go away (in some cases one of these changes will work, in others it won't). This is of course not the desired way to fix this problem, however, as it relies on making arbitrary changes and checking if it fixes the problem.
Solver Failure These methods may run without crashing, but their KSP/Newton's method steps do not converge. Proteus is eventually runs out of ideas of how to fix this and silently exits. These methods may be noticed by outputs which do not finish the time span recorded in the code. A verbose (-l5, or -l7 tend to make this really apparent) proteus will show the failure more clearly.
WaveTools These methods have obsolete calls to WaveTools (generally RandomWaves) which use an older set of arguments to the initialization. They tend to have failures that look like this:
The fix will be to carefully adapt the arguments to the new standard, creating new variables as needed.
Loose Print Statements (Arrays) These models have an easy to remove series of print statements still left in from testing. This is in the main .py file and goes like:
print gaugeLocationsprint columnLinesRemoving these lines removes the cumbersome printing for more readable use when needed. Their positioning may be useful if you have a way of parsing them, as several of these also have problems with gauges (and I'd guess that they all did at one point, hence the test prints) or other issues.Loose Print Statements (non-Array) These models have easy to remove print statements in the main files which produce unintuitive output for the user and clog up output. These are likely leftovers from tests at some point, but should be removed before practical use of the final product.
Image Unapparent: These models have images in their readme's which are unreachable. Most are from (old?) git-fat links, but some may have other issues.