The latest version was installed and I am now exporting version 3 r1 and r2 and am loading r3 simultaneously, all looks good so far! (r4 has the artificial spot log so I cannot test this one). I especially like the infomation telling you how far it has got with loading the data. However, I then started to test Version 2, the inoc logs for the first and then second repeats gave me the message below.
To add to the confusion, this morning (23/6) I checked the exported files for version 3 (all appear fine) and then tried to load inoc logs of version 2 again. This time version 2 repeat 1 worked, not sure why, I then tried repeat two (the experiment was crerated yesterday) and also created experiments for repeat 3 and 4 but none of these would accept an inoc log. I reloaded repeats 2, 3 and 4 and tried to load inoc logs, they all went in fine. I am currently loading spot logs and image logs. everytime the inoc logs would not go in they would give me the message above but thay have all gone in now!
I have also had the problem detailed above with spot logs and although I manage to get more data in each time I try it does seem to be a bit random as to when it accepts it. Also I briefly watched an image log going into ROD3 and it tells you how many images are left to export and how many spots of that image are left to export, for my experiment there are 480 images each with 384 spots, for one image of 384 spots it takes 2 minutes to export which if you work it out is 16 hours in total for one experiment. This may speed up after 6pm as the export files from yesterday finished at midnight (suggesting that it was quicker than 16 hours) but these are relatively small experiments in comparison to Adams over expression screen, once the imaging is automated we may also end up with more than double the amount of data that we have now. Is there a way of speeding this a little?
I think could be that ROD3 doesnt like it when I put in inoc and spot logs when there are files exporting (could also be the image log input as well).
The following error occurred: Exception thrown finding table type using
DatabaseMetaData.getTables()
org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:319)
org.datanucleus.jdo.JDOTransaction.commit(JDOTransaction.java:139)
uk.ac.cisban.rod.dao.DAO.addInoculation(DAO.java:842)
uk.ac.cisban.rod.data.handlers.ParseInoculationTask.doInBackground(ParseInoculationTask.java:117)
uk.ac.cisban.rod.data.handlers.ParseInoculationTask.doInBackground(ParseInoculationTask.java:32)
javax.swing.SwingWorker$1.call(Unknown Source)
java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
javax.swing.SwingWorker.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
This only appears to be a problem on mammoth. Perhaps when the new cisbclust comes around, this problem will disappear.