You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem: We identify that Maxent assume that variable files containing very tiny variation in dimensions information on the HEADER are considered to be geographical different.
Let me try to explain better:
We had some variable files that we needed to process using Maxent.
Some of these variables were cut on R (lets call cutted variables), others where left without processing because they already were in the correct size and scales (lets call original variables).
The original variables had data on their HEADER lines what I notice were rational values, that were clearly a conversion from a 32 bit float point number to string.
The cutted variables that we process on R had on their HEADER lines fields that I notice were rational values too, BUT they were clearly a conversion from a 64 bit float point number to string. That give EXTRA numbers on the least significance digits of the string due the higher precision of the 64 bit number.
Looking to several variables, all them had the same dimensions and sized,
BUT the rational numbers on the HEADER lines had the least significant digits with different number of cases.
That tiny difference lead to Maxent to refuse to process the files. The biologists using the tool spent a lot of time trying to understand what went wrong on their analysis, because they usually use Maxent directly from R, and the MaxEnt only presented on terminal a error saying that was unable to open a varible file; So we opened the Maxent java GUI to be able to see clearly what exception was occurring ding the process manually, and notice the error about the wrong geographical dimensions.
Bellow a set of HEADERs from the files which a example that cause us this problem.
Notice that FILE3 has a slightly different YLLCORNER value from others:
YLLCORNER -34.9583333333333
The same value on other files is:
YLLCORNER -34.958333333
In this case, we had processed the FILE3 on R and it generated the new file with this shuttle difference.
This happen on other similar fields with rational numbers.
That caused the problem related on this issue.
After noticing that, we adjust the FIELDS on all files, and them Maxent was able to run successfully!
I would like to known if we can assume that this situation is valid to be proposed as a minor adjustment to be made o Maxent.
I can try to do this adjust and submit a fix for it: when the difference between fields on the HEADER is this small, avoid blocking execution and adjust the parameters somehow automatically.
Bellow a example of the HEADER lines of variable files with the problem.
The problem: We identify that Maxent assume that variable files containing very tiny variation in dimensions information on the HEADER are considered to be geographical different.
Let me try to explain better:
We had some variable files that we needed to process using Maxent.
Some of these variables were cut on R (lets call cutted variables), others where left without processing because they already were in the correct size and scales (lets call original variables).
The original variables had data on their HEADER lines what I notice were rational values, that were clearly a conversion from a 32 bit float point number to string.
The cutted variables that we process on R had on their HEADER lines fields that I notice were rational values too, BUT they were clearly a conversion from a 64 bit float point number to string. That give EXTRA numbers on the least significance digits of the string due the higher precision of the 64 bit number.
Looking to several variables, all them had the same dimensions and sized,
BUT the rational numbers on the HEADER lines had the least significant digits with different number of cases.
That tiny difference lead to Maxent to refuse to process the files. The biologists using the tool spent a lot of time trying to understand what went wrong on their analysis, because they usually use Maxent directly from R, and the MaxEnt only presented on terminal a error saying that was unable to open a varible file; So we opened the Maxent java GUI to be able to see clearly what exception was occurring ding the process manually, and notice the error about the wrong geographical dimensions.
Bellow a set of HEADERs from the files which a example that cause us this problem.
Notice that FILE3 has a slightly different YLLCORNER value from others:
YLLCORNER -34.9583333333333
The same value on other files is:
YLLCORNER -34.958333333
In this case, we had processed the FILE3 on R and it generated the new file with this shuttle difference.
This happen on other similar fields with rational numbers.
That caused the problem related on this issue.
After noticing that, we adjust the FIELDS on all files, and them Maxent was able to run successfully!
I would like to known if we can assume that this situation is valid to be proposed as a minor adjustment to be made o Maxent.
I can try to do this adjust and submit a fix for it: when the difference between fields on the HEADER is this small, avoid blocking execution and adjust the parameters somehow automatically.
Bellow a example of the HEADER lines of variable files with the problem.
The text was updated successfully, but these errors were encountered: