You can participate if you really want.
But it would be really problematic and paintfull for you.

Randzo, how I can hack it?

Hi Cliff,

Sorry for the delayed answer - we are very busy with all the data coming in and hence a bit behind with the forum.

Here are some comments about your previous post:


Unfortunately, the result size scales with computing time - the longer a job runs, the more data we produce and transfer. We could make up additional tasks that don’t produce much output, but we don't think we should waste your time with stuff we don’t need for our research.


Incomplete results are absolutely taken care of and part of the overall setup - whatever is produced will be utilized.


Unfortunately no. We are interested in the electronic properties of our OPV candidates, which at the KS-DFT level are inherently determined by the MOs (which take up 90-99% of the result size). Again, if we drop the MOs, there is no point in doing this project - I don't see a way around this...


Well, that's what the project IS about... A lot of people have invested a lot of time to make CEP2 possible, and I don't think it would be wise to now scrap everything and do something else .


We actually avoid parts of the calculations and allow for some redundancy as long as it increases the overall efficiency.


CEP2 actually follows both routes: We start off with a SCREENING of a candidate library which we generated according to well defined rules and guidelines (in close collaboration with experimentalists from Stanford University). The returned results get piped into a big database and analyzed in order to prioritize this search, but also to learn and model structure-property relations. These are then used to actively DESIGN new molecular motifs beyond the initial library. Our insights will improve with the available amount of data. We hope that our database will be useful for organic electronics in general, not only for OPVs: even if a candidate is not interesting as an OPV it may end up being promising for OLEDs, OFETs, dyes, switches, ...


We actually do this and call it "quality rating". However, the point is that the formula for this will change in the course of the project due to our improved understanding. We also give our collaborators the possibility to create their own rating functions as they may have a different take on how to gauge a candidate. For this to work we have to store the results. In addition, a number of parameters in the quality function cannot be extracted efficiently on the grid - we do this in house after the results come back.


We are working on an overhaul of our webpage and it will have more information on this in the near future.


Absolutely - we always appreciate feedback and a lively discussion! I would like to make one more general point about the design of a WCG project from a researcher's perspective though: creating viable work for the grid is a nontrivial task! Complex workflows which are doable for a few hundred jobs on a cluster are often practically impossible for a few million different compounds in a highly heterogeneous environment like the WCG. As mentioned by Sekerob, we are thinking about different work units for different machines but this is tricky and will not be available in the immediate future.

Sekerob also pointed out that a farm like yours is somewhat of an exception (a cool one, if I may say so!) and your problem quite special - for the overwhelming majority of users the upload corresponds in size to a couple of youtube clips or MP3s per day. The issue is that the WCG setup is not really tailored for a machine like yours but has to accommodate a large crowd.

Best

Johannes
Harvard CEP2 team

herna, try seriously upping your <bwdown> value - to say, <bwdown>140586.756595</bwdown>

(of course, as I'm sure you're already aware, you'll have to shut down BOINC and it's advisable to make a backup of your client_state.xml file before making the change)

Yes, but it's keeping me from getting CEP2 beta WUs!