00:18 <rjo> sb0: the rationale for barrier was to be able to get a consistent hardware state and pdb state. having the barriers local to a pipeline would be fine.

00:23 <rjo> if a is run before b and b.prepare() or b.run() depend on a.analyze() having updated the pdb.

00:24 <rjo> e.g. find the qubit frequency, and then determine the rabi rate at that frequency.

00:25 <rjo> imho the "other pipelines" can be defined by the fact that barrier() is local.

00:25 <rjo> "flush()" might be a better name.

01:51 <sb0> rjo, ok. and do we want flush on parameters potentially modified, or just unconditional flush?

01:52 <sb0> flush with parameters is not totally straightforward, and likely will cause future maintainance issues as I have the impression that the pdb will see some refactorings

01:54 <sb0> rjo, also, considering this use case, does it make sense to be able to add the flush outside the experiment script - specify it as scheduler.submit() parameter?

03:25 <rjo> a "total" barrier (just wait for emptying of the respective pipeline stage) is ok imho.

03:27 <rjo> hmm. i think it is easier to do that with a dummy experiment in between that just does flush()

03:27 <rjo> the experiment batch would be [a, flush, b] which nicely exposes the interdependency.

03:48 <sb0> I thought about that, but guaranteeing the "a, flush, b" order of execution is problematic

03:48 <sb0> there might be timed runs in-between, or another experiment that the user has submitted with a higher priority

03:50 <sb0> well, it should still work in practice if the user doesn't do something stupid, but it feels a bit fragile

05:43 <GitHub51> [misoc] enjoy-digital pushed 1 new commit to master: http://git.io/vkvf2

05:43 <GitHub51> misoc/master 989d8a7 Florent Kermarrec: liteata: fix spelling & mistakes in doc

05:57 <GitHub111> [misoc] sbourdeauducq pushed 2 new commits to master: http://git.io/vkvUH

05:57 <GitHub111> misoc/master a9da892 Sebastien Bourdeauducq: litesata: doc fixes

05:57 <GitHub111> misoc/master 1e47cfc Sebastien Bourdeauducq: Merge branch 'master' of https://github.com/m-labs/misoc...

06:13 <GitHub109> [misoc] sbourdeauducq pushed 1 new commit to master: http://git.io/vkvIK

06:13 <GitHub109> misoc/master d50bb8c Sebastien Bourdeauducq: litesata: more doc fixes

08:18 <sb0> rjo, should the flush be a function call in the experiment, a schedule submit parameter, or both?

10:30 <kay2> hi

16:30 <sb0> something's not quite right about my aluminum evaporation attempt. I'm using an alumina crucible that I've wrapped in tungsten wire, and while the aluminum melts and it appears to deposit something, there's also a lot of a carbon-like substance that appears on the crucible

16:32 <sb0> it makes a nice light bulb, too, when pumping more than 100W into the wire (which is only a few cm long, the crucible is 3mm x 5mm or so)

16:33 <whitequark> what's that setup for?

16:34 <sb0> evaporation

16:34 <whitequark> well, yes

18:27 <rjo> sb0: right. makes sense to have flush be an artefact of an experiment w.r.t previous ones and not do the dummy experiment.

18:28 <rjo> which point in time would be relevant if flush was a submission parameter. before prepare() or before run()?

18:28 <rjo> i would make it a function call.

18:28 <rjo> ... to be used within an experiment.

19:47 <rjo> sb0: does the temperature you infer from the color match the temperature for the evaporation rate you see?

19:49 <rjo> you have to really burn lots of crap of you evap source before it gives of nice material. also the vacuum needs to be beaten by the evaporation rate.

22:51 <mithro> Has florent be around IRC much recently?