I did a really fascinating project with DAGman a few years back that seems in a similar vein.
Users needed to run a series of five FPGA layout-calculation layers, each step using a list of up to twenty different optimization methods, and find the result
of those five steps that converge to meet the timing requirement of the planned clock cycle of the chip.
The first layer had five different layout-optimization methods, the second had about a dozen, and the third had about twenty. The DAG managed the flow through
the layers - it would run all five of the first layer, then run the second layerâs dozen on each of those, for a total of sixty runs.
The top five timing results from the second layerâs 60 runs were selected by a post script, and then fed into a subdag for the third layer of 20 optimization
methods, for another 300 runs. The last two layers were pretty thin, as once a model filters through the first three the last two arenât too demanding when the top five third-layer results out of the 300 are fed into them.
This turned a multi-day manual workflow, requiring engineer intervention at each step, into an overnight workflow that was guaranteed to deliver either a
working chip layout or a definitive determination that a design change was needed. The chips in question were part of the testing equipment for the new LTAMDS (Lower Tier Air and Missile Defense) radar system, and the massive acceleration of the testing cycle
delivered corresponding huge acceleration in improvements to the radar design.
(I donât recall if I did an HTCondor Week presentation about it, and I seem to have misplaced the slide deck in any case, alas.)
DAGman is a very powerful tool, and I think that as you delve into it youâll find a whole swath of creative uses for it.
Good luck!
Michael Pelletier
Principal Technologist
High Performance Computing
Infrastructure & Workplace
Services
C: +1
339.293.9149
michael.v.pelletier@xxxxxxx
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of Lorenzo Mobilia
Sent: Thursday, October 26, 2023 3:07 AM
To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: [External] Re: [HTCondor-users] Non trivial way of using DAG
Hi Cole,
I will try to answer your questions shortly.
1.
What is the upper limit on the number of times this workflow can cycle? I assume it's a large number, but there must be some number of cycles you expect this work to be finished.
Well, what happens basically is a reduction of the dataset based on some calculation, so let's suppose that in the first subset we have n1 elements and after a cycle we end up with n2 elements, with n2<n1. So if this happens for every subset,
the D2 (which is the dataset obtained by merging all the subsets) should have a number of elements smaller than D1. We want to stop cycling when we cannot reduce the number of data further. The upper limit of this cycle I think then is reasonably the number
of data in the whole dataset.
1.
Are all N data subset computational jobs identical except for minor variations (different input/output files, arguments, etc)?
1.
How important is it for you to know which iteration of the cycle is on?
Actually not much. But I should think about that a little deeper.
Thank you for your time, for every other question/material/curiosity feel free to ask me!
This is a very interesting workflow to automate. I do have some questions regarding this:
-
What is the upper limit on the number of times this workflow can cycle? I assume it's a large number, but there must be some number of cycles you expect this work to be finished.
-
Are all N data subset computational jobs identical except for minor variations (different input/output files, arguments, etc)?
-
How important is it for you to know which iteration of the cycle is on?
Hi,
I am finding some difficulties in using DAG. Basically I need to
2. Split it in N subdataset
3. Perform some computation in these N subdataset
4. Merge these subdataset in another dataset D2
5. Restart the process (back to point 1) now using D2
And continuing until specific characteristics have been achieved by the final dataset. The problems are:
A. I don't know a priori how many times I need to split D1
B. I don't know a priori how many times I need to perform this cycle
The solution I came up with is to build a main which controls this flow, but after some cycles it crashes.
If anyone has some suggestions or is interested in this problem in order to have some other information, please let me know!
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to
htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}