WorkNotes/Kanban Pages/HelyxVerify.md

Generate differs in 10 and 100 runs

• New "new" format
• Init must check if both files are the same; if so, new format; if not, new new format.
• Validation needs pairs of files (Generated/Reference); assume short is always present, long is optional
• "update" can read the Validation directly
• If the generated file doesn't exist in the long run, ask again
• In "init", update the reference (this should be done inside Generator)\

0.20 Documentation

• Rundir
• Reduction
• Small-Fail/Large-Fail
• What is the absolute and relative differences

Not reducing

• ===THIS MAY BE UNNECESSARY WITH THE NEW CONFIG FORMAT===
• caseSetupDict.static, maybe?
• When there is no reduction, there is no need to build the short/long run things
  • The old format supports that, we just need to figure out when there are no reductions in init to generate the old format.
  • There is also a suggestion to change the run-dir when there is no reduction, which I'm not sure if possible due the other of "Expander"/"Reducer"...
  • Also, would need to have, in meta information, to have both (one option) rundirs.
    • This would help the other point of keeping the run-dir static for init, update and run.
    • Expanding all run-dirs at the start would save a few runs too.
• In the pipeline, the sequence is Expander, Reducer, Loader.
  • The Expander doesn't know if the case can be reduced or not, and can't make a judgement if we need 1 or 2 run-dirs.
  • Maybe Reducer could have a "reducer probability" kinda of thing that Expander could call to find out the number of run-dirs.
    • Function returns: caseSetupDicts that can be reduced but are not continuations, caseSetupDicts that are continuations and caseSetupDicts that can't be reduced. I'd like to make it an iterator, but I guess returning a Vec is good enough (specially since we need to sort the files in the file system to find out the continuations).
    • Problem: Variations need to be sorta-kinda expanded, 'cause they have more/replace caseSetupDicts
      • So Reducer needs to know about variations and the merge space from the Expander, and Expander needs to know about reductability from the Reducer.
      • (All this to know how many run-dirs we need...)
      • Default doesn't have long run (all caseSetupDicts are static); variation have short and long run (at least oneCaseSetupDict is reducible).
      • Rename the run-dir after expansion, if found anything that can be reduced?
      • Expand the short and long run-dirs always, and then just ignore/delete the long one if the case isn't reducible?
        • We need to remove it if it doesn't have a long validation either.
  • Should we follow the same idea for controlDicts?
• Need to document this properly #0.20 Documentation

verificationDict/validationDict

Idea for a Foam-formated file for Verify

validation {
	variables ("phi" "meanT");
	
	// Validation is run in sequence: "long" and "infinite" will not run if "short" passes its thresholds.
	// Names are free form, and we could use them to defined the run-dir, e.g., "short" validation will be run in ".run-short", "long" in ".run-long" and "infinite" in ".run-infinite".
	short {
		steps 10;
		generatedFile "postProcessing/10/blah";
		referenceFile "verification/10/blah";
		// No tolerances mean "it will warn if the values are not the same"
		
		// This makes the continuations explicit, by specificing files that form a single run.
		continuations (
			"system/caseSetupDict.initial"
			"system/caseSetupDict.continuation1"
			"system/caseSetupDict.continuation2"
		)
	}
	
	long {
		steps 100;
		generatedFile "postProcessing/100/blah";
		referenceFile "verification/100/blah";
		failIf {
			absolute 10;
			relative 10;
			operator and;  // will fail is the absolute difference is above 10 AND the relative difference is above 10;
		}
	}
	
	infinite {
		// With no steps, there is no reduction
		// (maybe we need something to tell that there is no reduction explicitly?)
		generatedFile: "postProcessing/20000/blah;"
		referenceFile "verification/20000/blah";
		failIf {
			absolute 20;
			relative 20;
			// no operator means OR, so example will fail if the absolute different is above 20 OR the relative difference is above 20
		}
	}
}

// This is used for filtering.
tags ("GIB" "AES" "compressible");

unstable {
	operatingSystem windows; // valid values: "windows", "linux", "all"
	reason "The script uses Python, and Python isn't usually available on Windows";
}

Pest:

foam = { SOI ~ entry ~ EOI }

// general stuff
quote = _{ "\"" }
semicolon = _{ ";" }
braces_open = _{ "{" }
braces_close = _ { "}" }
parentheses_open = _{ "(" }
parentheses_close = _{ ")" }
specials = { semicolon | braces_open | braces_close | parentheses_open | parentheses_close | WHITESPACE }
WHITESPACE = _{ " " | "\t" | NEWLINE }
COMMENT = _{ "//" ~ (!NEWLINE ~ ANY)+ }

// somewhat complex structures
single_word = @{ (!specials ~ ANY)+ }
quoted_word = @{ quote ~ (!quote ~ ANY)* ~ quote }
keyword = { quoted_word | single_word }
value = { keyword }

// main foam stuff
entry = { (dictionary | list | attribution)* } 

attribution = { keyword ~ value+ ~ semicolon }
dictionary = { keyword ~ braces_open ~ entry ~ braces_close }
list = { keyword ~ parentheses_open ~ value+ ~ parentheses_close ~ semicolon }

Migration plans?

• Side pipeline?
  • Current pipeline still exists, a new pipeline is build next to it with the new actors, with the new structures and "finder" sends requests depending on found files.
  • What about reporter?
• No actors?
  • New design is in early stages and I'm not sure how long till they are both feature compatible.
  • Also, how about the current tests?