How can you tell if

[marica69]

Hi,

Not sure if I have a problem or not but it seems that I may be having some type of issue.

When I look at the variouos boxes that I have running this, each shows me the generation and the best RMS. The problem is that I have two boxes that show a better RMS than what is on the stats page for over 12 hours now. This in itself is not that big a deal but it makes me wonder if the boxes are reporting properly or even reporting at all? I am not showing any queue on either machine that is in this situation and the numbers keep counting up.

The second thing that I noticed is that it seems that I am sending less work even though I am not using less computers (and the protein is shorter).

Is anyone else noticing anything like this? Does anyone have a suggestion on how to verify if the folding is actually going somewhere?

Thanks,
Donny

[Stardragon]

Just to clarify, where are you reading the RMSD value in your clients (which should be in fact referred to as pseudo-energy, there is no RMSD in CASP as we don't know the native structure)? You will note that the last protein came as low as 0.26 in pseduo-energy, so there is no reason for your lower results to not show up. Furthermore, check your error logs to make sure that your results were uploaded error-free.

[marica69]

I am looking at the value as reported by the monitoring software dfMon and or dfGUI. I have two machines that show a lower value, in the nines, than the one that shows up in the 12s (which showed up as soon as the next stats posted.

i will go to the machines that seem to be affected and check the error logs and report back what they say. I do not care about the reporting of the low nember per se but am worried that none of the work is going up nor being useful.

Oh yeah, dfMON actually jsut calls it best energy and then shows the generation it was created in.

Later,
Donny

[marica69]

Here is the error log. there are certainly entries here but I do not know how to parse them. I will check on one of the other boxes as well.

Donny

[marica69]

Here is a second error log. I do not know how much of htis is valuable or not so I am sending the whole thing.

[marica69]

Any ideas on what is going on or what I should do? I am going to be going out of town tomorrow and would like to make sure that the machines are doing something. Thanks,
Donny

[tpdooley]

The error log for the first system had 901 errors which seems to clear itself after some time.

The error log for the second system was having problems with a ticket that got lost/deleted. In the future, after seeing the same missing ticket message for a day, (all of yours were mentioning the same exact ticket) delete "receipt.txt" and try and upload again.

[marica69]

A new error on a different machine.Unable to read trajectory distribution t
xjxsrf3_protein_251, please create a new one. Hit return

Any ideas? The client will not restart and I do not know hwy it wants to do number 251 instead of starting a new one.

Donny

[Stardragon]

With respect to the error logs you posted, there are no significant errors there, so as long as you don't have any buffered files on your system, all is well.

As for the 251 trajectory distribution, again, if you have uploaded the files, you may safely delete the filelist. The 251 is a discrepancy that I believe has occured a few times before, but is not a serious error for you to worry about.

[marica69]

Elena,

First thanks for the support. I am a bit frustrated at the moment with the things happening on the clients and can not seem to figure out how to verify if they are doing any good.

3 of the machines have registered lower energy values than what my stats show. Does that mean that they are not uploading? One of them is already halway through the second full set of 250 gens.

I ended up deleting the whole directory and reinstalling on the machine with the 251 problem. I kept the old directory in case it was anything serious but after reading your post, I will delete it when I get done here. Thanks.

I posted under the tech support thread with a problem of a service that will not restart. It is on a remote machine that I can see the shared drive but do very little else on. I could call the shop and have them reboot it if that would do any good? It has been trying to restart (the service) for over an hour now but keeps getting a fatal error 002.003 I think.

Also, some of these machines are on a 10. network. They all seem to see out and in jsut fine (programs update, etc) but not sure if this could cause any of my problems?

Thanks again,
Donny

[Stardragon]

If you cannot restart the service manually, perhaps uninstalling and reinstalling the client as a service should do the trick. I'm not sure what's cousing the trouble on the remote machine, but as you suggest, a reboot of the machine could clear things up as well.

If you are able to upload fine, I don't see why the network should be causing any other problems.

As for the energy, I am not 100% certain what the 3rd party clients report for that and where it is read from. If you log in on the website, you will be able to see the lowest energy of any of the structures that you have successfully uploaded to our database. I am unable to say more at this point, because again I am not clear on where you are reading these values.

[bwkaz]

If you're reading the energy value from dfGUI (either for Windows or Linux), then it's coming from progress.txt.

This value is calculated by the clients locally when they produce that specific structure. It is then logged in progress.txt at whatever interval you have it set to update progress.txt at.

However, this is not necessarily the same value as the main DF servers will calculate for that same structure.

That's where the difference is coming from -- I believe the DF servers do more work when calculating the energy (more variables go into their fitness function), so they come up with a different number from what your client calculated before it updated progress.txt. It's not an indication of a failed upload.

[pfb]

Originally posted by bwkaz
If you're reading the energy value from dfGUI (either for Windows or Linux), then it's coming from progress.txt.

This value is calculated by the clients locally when they produce that specific structure. It is then logged in progress.txt at whatever interval you have it set to update progress.txt at.

However, this is not necessarily the same value as the main DF servers will calculate for that same structure.

That's where the difference is coming from -- I believe the DF servers do more work when calculating the energy (more variables go into their fitness function), so they come up with a different number from what your client calculated before it updated progress.txt. It's not an indication of a failed upload.

and the same for dfMon...

at the moment a majority of the local values match what is being shown on the stats but there maybe some that change server-side...

[tpdooley]

If the low energy scores are coming from dfGUI, it's (or at least was) - setup to remember the best score per generation. It didn't keep track of what protein size each of those scores came from. I open it up from time to time to see how many gens are buffered - and it updates the information for the gen that's currently being produced. So my low score at gen 195 that dfGUI is mentioning - could have been 6-12 months old. (And it's currently lower than my lowest score on the df stats sites..

After each protein, you might want to clear out the old scores by using the reset button on the Generation Stats tab.