The Case of the Contradictory Baselines

[Nathan Schneider]

I have run into an interesting conundrum when extending a workflow. Suppose I have a task t1 that is only ever required as a prerequisite on a non-baseline branch of some branch point:

task t0 > out { ... }
task t1 > out { ... }
task t2 < in=(Switch: 0=$out@t0 1=$out@t1) { ... }

The realizations are:

t0/Baseline.baseline
t1/Baseline.baseline (*)
t2/Baseline.baseline [Switch.0]
t2/Switch.1

After running the workflow, I then decide to add a new experimental condition: I insert a second branch point requiring t1 on its non-baseline branch, and also condition the behavior of t1 on this new branch:

task t1 > out :: foo=(NewSwitch: 0 1) { ... }
task t2 < in=(Switch: 0=(NewSwitch: 0=$out@t0 1=$out@t1) 1=$out@t1) { ... }

The problem is that the old t1 result (*) is now on a non-baseline realization:

t1/Baseline.baseline [NewSwitch.0]
t1/NewSwitch.1 (*)
t2/Baseline.baseline [Switch.0 NewSwitch.0]
t2/NewSwitch.1 [Switch.0]
t2/Switch.1 [NewSwitch.0]
t2/NewSwitch.0+Switch.1

This is bad because it changes the semantics of t1/Baseline.baseline, right? (Changing the order of the NewSwitch branches would change the semantics of t2/Baseline.baseline instead.) Is there any good workaround that would allow me to keep the completed results?

Or, is there/should there be a way to rename realizations that have produced results? Is it safe just to rename the directory on disk?

Happy New Year,

Nathan

[Jonathan Clark]

Nice example. Simple, but with subtleties. I had to draw it out to grok it.

I think you're describing two potential issues here:

(1) You're adding a parameter foo to t1 where there was previously no parameter. ducttape assumes that for new parameters there exists some value of that parameter that will exactly reproduce the Baseline.baseline configuration of that task. In this case, it would help to add an intermediate step in which you define task t0 > out { ... } :: foo=0 to make this step explicit. If this isn't true for you, I will then start up a debate about your software needing to support backward compatibility. :) This should allow the semantics of t1/Baseline.baseline to be preserved such that t1/Baseline.baseline (*) === t1/Baseline.baseline [NewSwitch.0]

(2) There's also the fact that t2/Switch.0+NewSwitch.1 is receiving its input file from t1. Perhaps you're concerned over whether it should receive it from t1/Baseline.baseline [NewSwitch.0] or from t1/NewSwitch.1. ducttape's answer is t1/NewSwitch.1 since NewSwitch is already committed to the branch 1. If you want to be able to access both branches of the parameter on t1, you'll need to add an additional branch point on the input of t2. The original semantics of t1/Baseline.baseline are still preserved when you consider that t2/Baseline.baseline [Switch.0 NewSwitch.0] will still use t0/Baseline.baseline and t2/Switch.1 will use t1/Baseline.baseline [NewSwitch.0]

Does this resolve things for you?

P.S. Does it could as a timely answer if I reply on the same day? ...of the month?

--
You received this message because you are subscribed to the Google Groups "ducttape-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ducttape-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Clark]

Also, here's my sketch in case it's useful to anyone, assuming anyone can actually read my handwriting.

​

 WP_20140201_09_13_16_Pro.jpg

​