Leginon

I tried to run the update: C:\Python25\python.exe schema_update.py in myami-2.1 folder, but still got the errors:

C:\Documents and Settings\donghua\Desktop\myami-2.1\dbschema>C:\Python25\python.
exe schema_update.py
?[32mconnected to db 'projectdb' on server 'leg.stanford.edu'?[0m
?[35mGetting release revision from myamiweb/xml/projectDefaultValues.xml?[0m
Traceback (most recent call last):
File "schema_update.py", line 11, in <module>
checkout_revision = updatelib.getCheckOutRevision()
File "C:\Documents and Settings\donghua\Desktop\myami-2.1\dbschema\updatelib.p
y", line 37, in getCheckOutRevision
release_revision = getReleaseRevisionFromXML(module_path)
File "C:\Documents and Settings\donghua\Desktop\myami-2.1\dbschema\updatelib.p
y", line 135, in getReleaseRevisionFromXML
raise ValueError('unable to parse XML file "%s"' % xmlfilepath)
ValueError: unable to parse XML file "myamiweb/xml/projectDefaultValues.xml"

The trunk you use to test dd image acquisition contains a non-back compatible change in database which is why you got the message asking you to run dbschema update. The update is meant to assign different Cs value for each TEM you use. This update would only exist in the trunk. You should not try to run the updates from the 2.1 branch which would not have this particular thing you need.

Try to do the update in the trunk folder you checked out.

If you still have the same problem, please do mysqldump of you databases and send them to me. I might be able to find out what has been corrupted when you go back and forth.

Anchi

We ran the update schema in the trunk version on the linux server but when we try to run it on the windows machine that controls the TEM (since the error message says to run it on the TEM) it still fails with the same error message as above.

Here is the message from mysqldummp --all-databases:

-- MySQL dump 10.11
--
-- Host: localhost Database:
-- ------------------------------------------------------
-- Server version 5.0.95-log

/*!40101 SET OLD_CHARACTER_SET_CLIENT=@CHARACTER_SET_CLIENT /;
/!40101 SET OLD_CHARACTER_SET_RESULTS=@CHARACTER_SET_RESULTS /;
/!40101 SET OLD_COLLATION_CONNECTION=@COLLATION_CONNECTION /;
/!40101 SET NAMES utf8 /;
/!40103 SET OLD_TIME_ZONE=@TIME_ZONE /;
/!40103 SET TIME_ZONE='+00:00' /;
/!40014 SET OLD_UNIQUE_CHECKS=@UNIQUE_CHECKS, UNIQUE_CHECKS=0 /;
/!40014 SET OLD_FOREIGN_KEY_CHECKS=@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 /;
/!40101 SET OLD_SQL_MODE=@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' /;
/!40111 SET OLD_SQL_NOTES=@SQL_NOTES, SQL_NOTES=0 */;

--
-- Current Database: `test`
--

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET latin1 */;

USE `test`;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE /;
/!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS /;
/!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS /;
/!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT /;
/!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS /;
/!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION /;
/!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2012-05-02 12:42:34

The Error message that instruct that you run the schema update on each TEM means that you need to Enter Cs value for each of the TEM when you run, in your case, schema-r15653.py on your main processing Linux computer. It does not mean that you should run the script on the computer that controls the TEM since it is usually not a complete installation of the whole package.

I've started upgrade instruction in Upgrade to Leginon System version 22 from version 21

If you have indeed updated to current dbschema and added Cs values in instruments.cfg at the scope computer but still get that error when acquiring image, something else is wrong.

When I said send me mysqldump I mean that I need the output file your get from the dump not the log. Send it thru e-mail to keep it private.

See http://emg.nysbc.org/boards/6/topics/478?r=487#message-487

Hi, Dong-Hua,

I looked at your database which gives a lot of history of what has happened. It might be a bug on our side when you did "get magnification" after already acquiring images. You now have two tem instruments pointing to the same physical scope. Any way, I think the fixing the database is the best to do now.

Option one, just add cs value to your new tem. Your old data will not have calibrations, but hopefully none of them is important to you.

Option two, delete the duplicated tem (id=6) and change the reference in MagnificationData to tem (id=4) that you have been using in the past.

I will send you the mysql command for option 2 privately.

Hi Anchi,

I used your option 2 and run the command:
mysql -u usr_object leginondb < fix_mag_tem.sql

then I took a DDD image successfully.

On the leginon client of microscope computer, I tried again for get_magnification, then I got this db schema update error again.

I tried to use the same way above to fix the problem, but it did not work any more. I already sent you the mysqldump output file.

Please help check. Thanks!

Donghua

Sorry, Donghua,

It looks like my reply yesterday didn't got send to the system properly, bad internet connection.

My fix was specific to your database condition at the time, which is why once you've fixed it once, it would not work the second time when it went wrong again.

You should use the database dump you sent me to restore to its original condition and try the fix again. After that, proceed to do calibrations WITHOUT
get_magnification step. That step must be the bug. With my fix, you should have the list of magnifications in the database so that you no longer need to
click that button again. I've started an issue on the bug #1790.

Let me know if this still does not work.

Anchi

Donghua,

From your new database dump, I see that by clicking "get magnification" button again before bug #1790 is resolved, you've produced another TEM instrument without Cs value (DEF_id=7). You just need to delete that and stop clicking 'get megnification' until you apply the change made for bug #1790 which I committed today.

The mysql command for this specific case is

delete from InstrumentData where DEF_id=7;

You don't need to use my option two fix any more at this point because once you delete this extra entry, Leginon will find the only remaining one to which the fix is already applied.

Just do not click "get magnification" again. You should start doing your calibration.

Bug #1790 is fixed. To apply the patch, follow instruction on Update within the same version using svn.

Thanks a lot! I did not update the Leginon version using svn. The problem was solved by "delete from InstrumentData where DEF_id=7;" from leginondb.