You guessed it, beta 6

[IronBits]

Cosmetics: Now that I've reached over 50%, it's very hard to read that percentage with the 'purple' progress bar background...

[bwkaz]

Well, I finally got off my lazy butt and redid the dfGUI Linux port.

Changes:

• Now uses Gtk+ 2 instead of Qt -- Qt had no vertical progress bar widget, and Gtk+ (especially version 2) looks better.
• UI was designed with Glade, which sets up a source directory that you can use GNU's autotools with -- so now the compile process consists of ./configure, make, make install (yes, I now have a make install).
• Unfortunately, no pixmaps (which would be the icons for the main window) yet. I'm not entirely sure how to get them working -- it'd probably require a bunch of hacking of the Makefile.am, at minimum.
• Edit: It also now contains my new e-mail address. Hopefully this one will be permanent. I'm also running through all the forums I'm subscribed to, and changing the list in each of them, FYI.

And of course, it'll only work with the beta DF client.

One issue I did notice was that this version of dfGUI did suddenly die on me the other day (it was a segfault). I'm not sure what the deal was, but I think it was that the DF client deleted either progress.txt or filelist.txt in between the time one function checked that it was there, and the time another function actually opened it. So I've added some more code to check against that; hopefully it's enough. If you see it segfault suddenly, though, let me know.

Oh yeah, there's also a new web page (hopefully the permanent one):

http://dfGUI.kadzban.is-a-geek.net

(I love DynDNS )

[IronBits]

make install?! Thanks for creating it.
I don't have any on *nix yet, but when I do, I'll give it a try.
It looks great! from the pics on your site of course.

[Mikus]

[LATE BREAKING NEWS: the client *finally* got off structure one and is now building a subsequent structure.]

My linux client has now spent six hours on the same residue of structure one of generation 137. Error.log shows nothing wrong -- only the time-out associated with trying to send the results of generation 136 (when I did *not* have my dial-out connection active). My flags for foldit are -g 0 -df -rt

The only "interesting" thing I've spotted is "earlier" generation numbers among the last files written (i.e., the files with the newest timestamps). The six most recent files (newest at bottom) were:

.foldtrajrc
filelist.txt
error.log
MyUserID_protein_137.trj
MyUserID_0_MyUserID_protein_102_0000039_min.val
MyUserID_0_MyUserID_protein_101_0000005_min.val.bz2

[Generation 101 is the last generation for which I uploaded results to the server. Generation 102 is the first generation for which I have *not* uploaded results to the server.]

The last four lines in filelist.txt are:

./fold_0_MyUserID_0_MyUserID_protein_136.log.bz2
./MyUserID_0_MyUserID_protein_136_0000010.val
CurrentStruc 0 1 124 137 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.800 3.400 3557.926 -----------------------HHHHH-------------------------------HHHH----------------------HHHH-------
1530e1ea221299b24fa3c17b8baa2702

mikus

[Brian the Fist]

Originally posted by IronBits
It seems to hang for a very long time just after 95ish until just past 100 or there abouts...
ahhhhh... progress
I haven't payed any attention to how much memory is required.
I have 512mb of DDR in all my 'work/game' boxen and 256mb DDR in my crunchers.

Just remember, a watched pot never boils

[Brian the Fist]

Originally posted by IronBits
Cosmetics: Now that I've reached over 50%, it's very hard to read that percentage with the 'purple' progress bar background...

Pardon me, but what the heck are you talking about anyways? I have no clue what you are referring here to, assuming this is directed towards me...

[Brian the Fist]

Originally posted by Mikus
[LATE BREAKING NEWS: the client *finally* got off structure one and is now building a subsequent structure.]

My linux client has now spent six hours on the same residue of structure one of generation 137. Error.log shows nothing wrong -- only the time-out associated with trying to send the results of generation 136 (when I did *not* have my dial-out connection active). My flags for foldit are -g 0 -df -rt

The only "interesting" thing I've spotted is "earlier" generation numbers among the last files written (i.e., the files with the newest timestamps). The six most recent files (newest at bottom) were:

.foldtrajrc
filelist.txt
error.log
MyUserID_protein_137.trj
MyUserID_0_MyUserID_protein_102_0000039_min.val
MyUserID_0_MyUserID_protein_101_0000005_min.val.bz2

[Generation 101 is the last generation for which I uploaded results to the server. Generation 102 is the first generation for which I have *not* uploaded results to the server.]

The last four lines in filelist.txt are:

./fold_0_MyUserID_0_MyUserID_protein_136.log.bz2
./MyUserID_0_MyUserID_protein_136_0000010.val
CurrentStruc 0 1 124 137 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.800 3.400 3557.926 -----------------------HHHHH-------------------------------HHHH----------------------HHHH-------
1530e1ea221299b24fa3c17b8baa2702

mikus

Please remember I'm a little slow here, so is this a comment or a bug report? Are you saying you're missing 36 generations of files? It is normal for the program to get stuck sometimes, you just need to be patient.

[IronBits]

Originally posted by Brian the Fist
Pardon me, but what the heck are you talking about anyways? I have no clue what you are referring here to, assuming this is directed towards me...

Whoops!

[pointwood]

Howard: I think IB needs a little kick - he should be easy to hit with that target

I believe he is talking about the dfGUI - the cool monitor app. Digital Parasite has created.

[Mikus]

Originally posted by Brian the Fist
Please remember I'm a little slow here, so is this a comment or a bug report? It is normal for the program to get stuck sometimes, you just need to be patient.

It started as a bug report -- six hours on one structure GREATLY exceeds my patience -- it looked to me as though the client was stuck FOREVER. Then when the client *finally* moved on to a subsequent structure it became a comment.

But please take a look at the CurrentStruc line in my filelist.txt. Is that normal (for linux) ?

mikus

[m0ti]

Originally posted by Mikus
It started as a bug report -- six hours on one structure GREATLY exceeds my patience -- it looked to me as though the client was stuck FOREVER. Then when the client *finally* moved on to a subsequent structure it became a comment.

But please take a look at the CurrentStruc line in my filelist.txt. Is that normal (for linux) ?

mikus

I had one fold wich was stuck for about 12+ hours... not worth it to constantly check your client... just make sure it's up and running. Otherwise, it's slightly depressing.

[Digital Parasite]

Wow, my 3rd structure laxness value is higher than I have ever seen it before:

CurrentStruc 0 30 124 153 1 17 7.005 -1783.355 -449.109 -788.262 55715020.000 2.250 4.300 12516.409 -------------------HHHHH------------------------------------------------------------------------

Howard: Did you say that you expected 2.x or 3.x RMSD values with beta6 or where you talking about something you are currently working on but havn't released yet?

Jeff.

[bwkaz]

Originally posted by Mikus
But please take a look at the CurrentStruc line in my filelist.txt. Is that normal (for linux) ?

Seems OK to me... Do you mean the 10 million numbers? Those are just the "best energy found so far in this generation" numbers. They're 10 million because it's still (according to filelist, anyway) working on the first structure. Once the client does a progress.txt update, those numbers will fall to whatever your best RMSD so far is in that generation.

[Brian the Fist]

Originally posted by Mikus
It started as a bug report -- six hours on one structure GREATLY exceeds my patience -- it looked to me as though the client was stuck FOREVER. Then when the client *finally* moved on to a subsequent structure it became a comment.

But please take a look at the CurrentStruc line in my filelist.txt. Is that normal (for linux) ?

mikus

Looks 'normal' enough to me, I'm not sure what you're getting at really. As for the 6 hour thing, just run it in quiet mode so you don't have to see it

[Brian the Fist]

Originally posted by Digital Parasite
Wow, my 3rd structure laxness value is higher than I have ever seen it before:

CurrentStruc 0 30 124 153 1 17 7.005 -1783.355 -449.109 -788.262 55715020.000 2.250 4.300 12516.409 -------------------HHHHH------------------------------------------------------------------------

Howard: Did you say that you expected 2.x or 3.x RMSD values with beta6 or where you talking about something you are currently working on but havn't released yet?

Jeff.

Now does it really matter what I say I expect anyways?
It appears to me that the most recent change (which incidentally causes the sidchains to become 'fixed' in place once they find low energy pockets) has caused the structure to get 'stuck' more (and thus the laxness must get higher). This is not totally surprising as we are removing degrees of freedom. I believe the solution is to compromise, and try to use the fixed sidechain when possible, but if a collision occurs, default to the other approach. That wil be an important change for next week when I release what may hopefully be one of the last test algorithms (for now).

[IronBits]

When this thing gets released, I hope the time to completion will go down alot.
4 days, 10 hours, 33 minutes and only 65% done working on the same protein is a long time. What if it crashes and I lose it all? (not my computers tho! )
The RMS value has gone from a low of 5.2 up to 5.79 (seems to be going backwards).
Is this beta trying to figure out the 'give up' trying limit for you?
Are you getting any usefull data out of this as it goes along working on this, or do you need to wait for it to finish?
Also, when you first start up a 'WorkUnit', it races like crazy to run thru the protein, we get 1,000 points, then slows down as it starts to work harder on it.
What's to prevent someone from downloading a WU, let it run thru once quickly, stop it, delete the WU, download another, over and over to fluff their points and not be of much help to the science part of it?

[Kileran]

"Thanks again for all your assistance in making the client better and smarter."

Oh no, it's THINKING!!!!!!

[Aegion]

Originally posted by IronBits
When this thing gets released, I hope the time to completion will go down alot.
4 days, 10 hours, 33 minutes and only 65% done working on the same protein is a long time. What if it crashes and I lose it all? (not my computers tho! )
The RMS value has gone from a low of 5.2 up to 5.79 (seems to be going backwards).
Is this beta trying to figure out the 'give up' trying limit for you?
Are you getting any usefull data out of this as it goes along working on this, or do you need to wait for it to finish?
Also, when you first start up a 'WorkUnit', it races like crazy to run thru the protein, we get 1,000 points, then slows down as it starts to work harder on it.
What's to prevent someone from downloading a WU, let it run thru once quickly, stop it, delete the WU, download another, over and over to fluff their points and not be of much help to the science part of it?

You don't get points that way. Its on a progressive scale with you gaining far more points for the later 50 units than the first 1,000 structures.

[Mikus]

Originally posted by bwkaz
Seems OK to me... Do you mean the 10 million numbers? Those are just the "best energy found so far in this generation" numbers. They're 10 million because it's still (according to filelist, anyway) working on the first structure. Once the client does a progress.txt update, those numbers will fall to whatever your best RMSD so far is in that generation.

Thanks -- that explains it. I do not have a progress.txt file, so the client NEVER gets around to changing the 10 million numbers in the filelist.txt file.

mikus

[Welnic]

Originally posted by Mikus
Thanks -- that explains it. I do not have a progress.txt file, so the client NEVER gets around to changing the 10 million numbers in the filelist.txt file.

mikus

Do you not have a progress.txt file because you are running a -g 0 switch?

[tpdooley]

IronBits - take a look at all the movies. For preceeding betas, some would hit a low around gen 20-40, and then it make a wild swing up and come down 20-60 generations later. Others would make a steady drop with little ups all the way to gen 100, and then run out to gen 250 without breaking that low.

[Mikus]

Originally posted by Welnic
Do you not have a progress.txt file because you are running a -g 0 switch?

Yes. [I mentioned it in my initial post. And I don't recall reading in the beta info that that would be a no no.]

mikus

[Welnic]

Originally posted by Mikus
Yes. [I mentioned it in my initial post. And I don't recall reading in the beta info that that would be a no no.]

mikus

I don't think that running with -g 0 is that good an idea with the beta. With that setting the filelist.txt will only be written at the end of every generation. If the program dies or your computer goes down you lose everything that you have done so far in the latest generation. Once you get off of generation 0 then it runs slow enough that the default setting of 5 is not writing to the hard drive that often.

Of course if you quit the client the way that you are supposed to then it writes to the filelist.txt and you are set. So if you are not worried about it going down then that is fine. But as you have discovered you can't see how well one of your clients is doing, either. That is the main reason that I have been running with -g 1.

[AMD_is_logical]

Originally posted by m0ti
It appears to me that filelist.txt is being used for three purposes:

1) Pairing the files to be uploaded (log with val).

2) Listing the files to be uploaded.

3) A location for saving additional information on the current state of the current fold.

I think that these 3 functions have been arbitrarily put together in a single location. It would (IMO) be preferable to do the pairing ahead of time (ie archive the val and log files together with suitable protection), do the listing of these files for upload in filelist.txt (which probably wouldn't require protection then), and a second file (state.txt?) for storing state info.

I think m0ti has a very good point here. I agree it would be better for the client to put the result of crunching a generation in a single file. This file could be created as a temporary file in the DF directory, and then renamed after it is complete. The final name could be something like "foldz_xxxxx_yyy" where xxxxx is which set of generations, and yyy is the generation within that set. The renaming insures that any file of the appropriate form (foldz_* in this example) is an output file complete and ready for upload.

Now work can be removed from a no-netting computer without even shutting down the client on that computer. All that is needed is to move the files foldz_* to the uploading computer. Before uploading, the filelist.txt file can be generated as the output of "ls" or "dir" with the appropriate switches. (If the number fields in the filename are fixed length with leading zeros, then the sort done by ls/dir will put the names in the right order.) With the state info in a seperate file, the filelist.txt no longer needs protection. This will make harvesting results from no-netting computers much easier.

With Stanford shutting down its old genome client (which could no-net), many people are looking for another project. They will not be moving to the new Stanford client because they want to no-net. When I see these people post asking for suggestions, I would like to be able to suggest DF. I hesitate to do so, however, because the current beta client makes it much harder to harvest results than these people are used to.

Things could be made even more robust by allowing the server to accept generations in any order. I assume that when a new set of generations is started it gets a unique ID, and all generations belonging to this set have this ID. I see no reason why the server can't accept the generations for this ID in any order (quietly dropping duplicates of a generation into the bit bucket). This would solve the problem of hundreds of generations of work being lost because of some glitch in an earlier generation.

I feel that ease of no-netting and robustness are things that will have an important impact on the number of people crunching for DF, and thus it is worth putting some effort into improving them.

[m0ti]

Originally posted by AMD_is_logical

...

Now work can be removed from a no-netting computer without even shutting down the client on that computer. All that is needed is to move the files foldz_* to the uploading computer. Before uploading, the filelist.txt file can be generated as the output of "ls" or "dir" with the appropriate switches. (If the number fields in the filename are fixed length with leading zeros, then the sort done by ls/dir will put the names in the right order.) With the state info in a seperate file, the filelist.txt no longer needs protection. This will make harvesting results from no-netting computers much easier.

With Stanford shutting down its old genome client (which could no-net), many people are looking for another project. They will not be moving to the new Stanford client because they want to no-net. When I see these people post asking for suggestions, I would like to be able to suggest DF. I hesitate to do so, however, because the current beta client makes it much harder to harvest results than these people are used to.

Things could be made even more robust by allowing the server to accept generations in any order. I assume that when a new set of generations is started it gets a unique ID, and all generations belonging to this set have this ID. I see no reason why the server can't accept the generations for this ID in any order (quietly dropping duplicates of a generation into the bit bucket). This would solve the problem of hundreds of generations of work being lost because of some glitch in an earlier generation.

I feel that ease of no-netting and robustness are things that will have an important impact on the number of people crunching for DF, and thus it is worth putting some effort into improving them.

That's why I've been working on dfQ. It's primarily intended for no-netting. Yes, it does shut down the client to transfer the files, but it's designed to be pretty fail-safe and get the client up and running quickly; from what I've seen on my home machine, it take about 1-2 seconds to harvest the results (it later transfers them to the server in parallel with the folding).

I'm trying to support as many features as I can; in the last version (rc1) I've got orphaned support working.

Planned stuff:

1) Support multiple users/handles.
2) Stats... everyone loves stats.
3) Installation as a service for windows folk.

Of course development would be faster if the rest of my life didn't keep getting in the way.

[Brian the Fist]

Originally posted by AMD_is_logical
I think m0ti has a very good point here. I agree it would be better for the client to put the result of crunching a generation in a single file. This file could be created as a temporary file in the DF directory, and then renamed after it is complete. The final name could be something like "foldz_xxxxx_yyy" where xxxxx is which set of generations, and yyy is the generation within that set. The renaming insures that any file of the appropriate form (foldz_* in this example) is an output file complete and ready for upload.

Now work can be removed from a no-netting computer without even shutting down the client on that computer. All that is needed is to move the files foldz_* to the uploading computer. Before uploading, the filelist.txt file can be generated as the output of "ls" or "dir" with the appropriate switches. (If the number fields in the filename are fixed length with leading zeros, then the sort done by ls/dir will put the names in the right order.) With the state info in a seperate file, the filelist.txt no longer needs protection. This will make harvesting results from no-netting computers much easier.

Things could be made even more robust by allowing the server to accept generations in any order. I assume that when a new set of generations is started it gets a unique ID, and all generations belonging to this set have this ID. I see no reason why the server can't accept the generations for this ID in any order (quietly dropping duplicates of a generation into the bit bucket). This would solve the problem of hundreds of generations of work being lost because of some glitch in an earlier generation.

Now you know what happens when you assume... In short, no, generations must be uploaded in order and this cannot and will not change. Please keep in mind many of the policies we have established ensure we maintain data integrity and discourage cheating. These principles, especially data integrity, are of the utmost importance to a project like this, even if it results in inconveniencing a fraction of the users. However we will always so as much as possible to make it convenient for as many as possible of course.

Again wth robustness, that is (at least part of) the point of this beta testing. We have close to 50 people running the beta test, or so it appears. I have not heard one complaint about anyone's box crashing and losing work and having to start over, since about beta 4 maybe. This tells me the client is very robust. Yes, it is inherently risky in that IF you should accidentally delete a critical file, or something like that, you may have no choice but to restart. But in practice how often will this really happen?

In response to IB's comment above, 4 days working on the same protein structure is nothing actually. In molecular dynamics, scientists simulate the same protein structure moving over time for weeks or months on multi-CPU beasts, and they do not get anywhere as close to the folded state as we are getting in a few hours (albeit with cheating by using the RMSD as the scoring function). Each CPU now is carrying out a FULL protein folding simulation, from start to finish.

I'm not sure how many people get this yet, but the idea is that by doing 5000 or so full folding simulations in parallel (one per CPU running DFP), some will lead to useless dead ends, and a few, just by chance, will head straight to the correct folded structure, missing any local minima or 'kinetic traps' on the way. Thus once we get this going, we only really need each CPU to run through the 250 generations (or whatever) once or twice to hopefully get enough folding simulations to include one that succeeds. In principle this is similar to the way Folding@Home achieves its simulations (as I understand it). They perform multiple MD simulations, one per CPU, and a few lucky ones fold 'earlier' than the rest. Thus although the simulation may run for only 1 ns, for those 'lucky' ones the effective time could be 1000 times are long. You can think of the effective simulation times as being distirbuted by a Bell curve. Most are in the middle and roughly the same. But a few are extreme and these are the interesting ones. The more simulations you run, the more those 'extreme' cases come up, and the more extreme they get. It is a shockingly simple principle and is remarkably effective.

[Brian the Fist]

If you dont mind, could a few people again please post the 'Currentstruc' lines from your filelist.txt, from simulations that are well under way (say gen. 100 or beyond). I just want to see hwo high the 'laxness' parameters are getting for people now compared to the previous algorithm(s) as I suspect they are higher.

[m0ti]

CurrentStruc 0 42 124 142 1 9 6.867 -970.243 1219.267 -199.613 11928342.000 1.400 2.600 1163.097 ---------------------------------HHHHHHH--------E------------------E----------------------------

[Welnic]

CurrentStruc 0 50 124 106 1 37 6.490 -1291.330 1503.922 175.628 20169342.000 2.650 5.100 38287.938
-------------------------HHHH-------------------------------------------------------------------
CurrentStruc 0 36 124 141 1 27 8.525 -33.411 872.953 306.847 8415750.000 1.050 1.900 437.250
------------------------------------------------------------------------------------------------
CurrentStruc 0 26 124 185 1 14 7.955 -1236.032 376.299 -317.949 13478783.000 1.400 2.600 1163.090
-------------------HHHHHHHHHHH------------------------------------------------------------------
CurrentStruc 0 4 124 168 1 2 6.741 201.624 541.282 19.737 393151.688 1.550 2.900 1768.927
--------------------------------------------------------------------------------HHHHHHHHH-------

[Aegion]

CurrentStruc 0 11 124 180 1 4 6.410 -681.752 294.804 -40.262 1689967.500 1.550 2.900 1768.917 -------------------HHHHH-----------HHHHHH-------------------------------------------------------

[bwkaz]

CurrentStruc 0 1 124 129 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.300 2.400 879.465 ------------------------HHHHHHHH---HHHHH---------------HHHHH------------------------------------

This is from (as you can see) the start of gen 129. Side note: A fair number of helices, actually. Wow.

[CSMan]

CurrentStruc 0 51 124 167 1 39 5.740 -2457.953 -254.762 -1520.365 129800008.000 1.050 1.900 437.250 ------------------HHHHHHH-----------------------------------------------------------------------

[AMD_is_logical]

From my 4 nodes:

CurrentStruc 0 36 124 144 1 31 6.640 -1350.776 51.214 -414.401 16910420.000 1.150 2.100 578.262
-----------------------------------HHHHHHH-------------HHHHH------------------------------------

CurrentStruc 0 41 124 215 1 37 6.813 -3031.701 -1304.664 -1640.530 174910608.000 2.000 3.800 6222.836
--------------------HHHHH--HHHHH-------------------------HHHHH----------------------------------

CurrentStruc 0 1 124 158 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.500 2.800 1538.192
---------------------HHHHHHHHHH----HHHH-----------E--E-HHHH-------------------------------------

CurrentStruc 0 11 124 137 1 5 7.164 -815.084 -182.907 -91.048 2382009.250 1.650 3.100 2339.405
-------------------------HHHH-----HHHH------------------HHHH------------------------------------

[Angus]

CurrentStruc 0 46 124 108 1 4 5.785 128.576 1505.472 591.034 23804938.000 1.650 3.100 2339.394 ------------------HHHHHH-------------------------------HHHHH------------------------------------

CurrentStruc 0 21 124 114 1 6 6.839 -1252.899 134.517 -183.520 7215765.500 1.150 2.100 578.263 -------------------HHHH-------------------------------------------------------------------------

CurrentStruc 0 1 124 112 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.050 1.900 437.250 ---------------------------HHHH---------------------------HHHH--------------------------HHHH----

CurrentStruc 0 41 124 85 1 14 6.721 -2105.635 -687.760 -1102.256 80349920.000 1.600 3.000 2034.268 ----------------------------------------------------------HHHHH---------------------------------


These four clients were all started at the same time on one boxen.

[dano]

CurrentStruc 0 26 124 51 1 13 7.142 -1295.116 191.320 -318.528 14008556.000 1.600 3.000 2034.267
-------------------HHHHHHHHH-------HHHHHH
---------------HHHHHH----------------------------------
CurrentStruc 0 3 124 241 1 1 6.604 1381.281 1936.564 66.357 5658217.500 1.200 2.200 665.003
---------------------HHHHHHHH-------------------------------------------------------------------

[IronBits]

CurrentStruc 0 1 124 222 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.400 2.600 1163.093 ---------------------HHHHH-HHHHH--HHHHHH------------------HHHH----------------------------------
Howard, thanks for the explanation!!!
I get to work on my very own from start to finish, sounds great

[IronBits]

CurrentStruc 0 1 124 222 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.400 2.600 1163.093 ---------------------HHHHH-HHHHH--HHHHHH------------------HHHH----------------------------------

[Georgina]

gen. 144

CurrentStruc 0 1 124 144 1 0 10000000.000 10000000.000 -10000000.000 0.000 0.000 1.550 2.900 1768.917 ---------------------HHHHHHHHH-------------------------------------------------------HHHHHH-----
1f3e172143df229d872f569c08525fc4

[Hzull]

CurrentStruc 0 41 124 168 1 28 5.866 -1200.515 196.646 -441.164 17386992.000 1.400 2.600 1163.093 -------------------HHHH-HHHHH-------------------------------------------------------------------

CurrentStruc 0 41 124 172 1 20 7.974 -2971.448 -509.653 -1358.493 129083864.000 1.500 2.800 1538.189 ------------------------------------------------------------------------------------------------

CurrentStruc 0 51 124 129 1 35 6.772 -1488.998 -183.417 -612.739 22658662.000 1.250 2.300 764.753 -------------------HHHHH--------------------------------HHHHHH----------------------------------

CurrentStruc 0 6 124 101 1 2 6.735 -1210.602 -101.636 -52.211 2050973.500 1.350 2.500 1011.386 ------------------------------------------------------------------------------------------------

The first two are from seperate WXP boxes. The last two are from a dual processor linux box.

[pointwood]

CurrentStruc 0 41 124 123 1 4 7.207 -1320.863 221.989 -497.371 18571794.000 1.200 2.200 665.003 -----------------------HHHHHHHHHHHHHHHHH---------------------------------------------HHHHH------