yafu ignoring yafu.ini

[chris2be8]

Hello,

I've found that yafu ignores yafu.ini even though it's called with a full path to the executable and yafu.ini is in the same directory.

Eg (from the log of my script calling it):

Mon Oct  7 15:25:54 2019 =>"/home/chris/yafu/yafu" 'factor(2387558269606450709622009990622002596238721211851386839362889832990611106360073)' -v -p -ecm_path /usr/bin/ecm -logfile ggnfs.log -threads 4
10/07/19 15:25:54 v1.34.5 @ rigel, 
10/07/19 15:25:54 v1.34.5 @ rigel, ****************************
10/07/19 15:25:54 v1.34.5 @ rigel, Starting factorization of 2387558269606450709622009990622002596238721211851386839362889832990611106360073
10/07/19 15:25:54 v1.34.5 @ rigel, using pretesting plan: normal
10/07/19 15:25:54 v1.34.5 @ rigel, no tune info: using qs/gnfs crossover of 95 digits
10/07/19 15:25:54 v1.34.5 @ rigel, ****************************

But yafu.ini in /home/chris/yafu definitely contains tune info for this system (the last line):

chris@rigel:~/yafu$ cat yafu.ini 
%B1pm1=100000
%B1pp1=20000
%B1ecm=11000
%rhomax=1000
threads=4
%pretest_ratio=0.25
%ggnfs_dir=..\ggnfs-bin\Win32\
ggnfs_dir=/home/chris/lasieve4_64/
ecm_path=/usr/bin/ecm
%ecm_path=..\gmp-ecm\bin\x64\Release\ecm.exe
%ecm_path=../ecm/current/ecm
tune_info=       Intel(R) Xeon(R) CPU E5-4650 0 @ 2.70GHz,LINUX64,1.73786e-05,0.200412,0.400046,0.0987873,98.8355,2699.98
tune_info=AMD Athlon(tm) II X2 240 Processor,LINUX64,1.29672e-05,0.208991,0.561878,0.0975652,95.8178,2800.02
tune_info=Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz,LINUX64,1.51053e-05,0.203897,0.33923,0.101122,97.4879,3209.99

I managed to get round this by adding -ecm_path /usr/bin/ecm to the command. But it was rather confusing. It would help if yafu called with -v said whether it was reading yafu.ini or not.

Another point was that when I ran tune() the first time it spend a few minutes running QS, then aborted because it could not find the lattice siever. I had to run yafu 'tune()' in the same dir as the lattice siever to make tune work. It would have saved time if tune() checked if it can find the lattice siever *before* benchmarking QS.

Chris

[bsquared]

Thanks for the report - not something I test out very often. I've been pretty busy lately but will try to look into it soon.

[bsquared]

Fix checked into yafu-wip r379.

Behavior is now: If you specify -xover, that will be preferred over what is in tune_info, else if valid tune_info is found, use that xover, else use default xover (currently 95).
Oh, and I now check for sievers before starting any qs tuning, thanks for that suggestion.

[chris2be8]

The tune info was just a side issue, the problem for me was that is was ignoring ecm_path in yafu.ini so ran ECM single threaded. And ignoring ggnfs_dir when running tune.

And a message saying whether it had found yafu.ini would have helped me work out what was going wrong.

But thanks for fixing tune to check for sievers first.

Chris

[bsquared]

It should not be ignoring yafu.ini... let me know if it still seems to be doing that (I forgot to include a message that yafu.ini was found, sorry).

[chris2be8]

Hello,

I'm afraid I don't know if the latest version ignores yafu.ini. The only option to download anything I can find on http://sourceforge.net/projects/yafu/ just gives me yafu-1.34.zip which is exactly the same as the version I'm running. It's probably my slightly old web browser causing the problem, but trying Firefox ESR didn't work either.

I'm not too worried because I can get round the problem by passing yafu parms from my script.

Chris

[bsquared]

Originally Posted by chris2be8

Hello,

I'm afraid I don't know if the latest version ignores yafu.ini. The only option to download anything I can find on http://sourceforge.net/projects/yafu/ just gives me yafu-1.34.zip which is exactly the same as the version I'm running. It's probably my slightly old web browser causing the problem, but trying Firefox ESR didn't work either.

I'm not too worried because I can get round the problem by passing yafu parms from my script.

Chris

Everything I've been doing lately has been in the "wip" branch of the repository and will involve a build from source to use. If you are not accustomed to doing that, and if you already have a workaround, then that's probably easier.

[BudgieJane]

I don't know if this is the right place to put this, but I have been having a couple of instances of odd behaviour with regard to yafu finding yafu.ini which are worthy of notice.

To begin with, my yafu program is in C:\Users\Jane\Documents\Maths\yafu\Versions\yafu-2.07\yafu-x64.exe and yafu.ini in the same directory contains the following lines for ggnfs

%ggnfs_dir=..\..\..\ggnfs-x64\
ggnfs_dir=C:\Users\Jane\Documents\Maths\ggnfs-x64\

I also have a yafu.ini file in C:\Users\Jane\Documents\APLapps\Numbers, and the ggnfs entry in that file is this one only:

ggnfs_dir=..\..\Maths\ggnfs-x64\

Looking at docfile.txt I notice that it says

These same flags can be specified in a file named yafu.ini in the same
directory as the executable.

Now normally I run yafu by means of a syscmd issued by an application running in C:\Users\Jane\Documents\APLapps\Numbers, and to try to discover what was causing me trouble the other day I decided to run yafu from the command line in that directory:

 ..\..\Maths\yafu\Versions\yafu-2.07\yafu-x64 factor(19893371953449789754112768668082453895521044869721500349740173084074096716249047839111944539619046971725287) -forceDLP -v -v -v -noecm  -R -logfile io\yafulog.txt -of io\out02.txt >testop3.txt

It's a good thing I redirected the screen output to that file (testop3.txt) because normally that output flies past on the screen at the speed of light, and you can't see what's going on. In this file, I saw many times lines like the following:

syscmd: ..\..\Maths\ggnfs-x64\gnfs-lasieve4I12e.exe -v -f 1502000 -c 7000 -o rels0.dat -n 0 -a nfs.job

You will notice that the command begins with just 2 levels of ..\, not three or none, so the reference to ggnfs must have come from yafu.ini in C:\Users\Jane\Documents\APLapps\Numbers, i.e. where I called the program from and not from the yafu.ini in the same directory as the executable as stated in docfile.txt.

Hence my, and maybe other people's, confusion.

Would it be possible to put the full path to the yafu.ini file on the yafu log file in a future release?

[bsquared]

Originally Posted by BudgieJane

Would it be possible to put the full path to the yafu.ini file on the yafu log file in a future release?

You are correct, it tries to parse yafu.ini from the directory where the command is run. I added the attempted parse location to session.log:

02/09/22 12:04:16, =====================================
02/09/22 12:04:16, System/Build Info: 
02/09/22 12:04:16, YAFU Version 2.08
02/09/22 12:04:16, Built with Microsoft Visual Studio  1922
02/09/22 12:04:16, Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
02/09/22 12:04:16, detected Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz
detected L1 = 32768 bytes, L2 = 17301504 bytes, CL = 64 bytes
02/09/22 12:04:16, using 1 random witness for Rabin-Miller PRP checks
02/09/22 12:04:16, Cached 664579 primes: max prime is 9999991
02/09/22 12:04:16, Parsed yafu.ini from H:\src\c\yafu

[BudgieJane]

Originally Posted by bsquared

You are correct, it tries to parse yafu.ini from the directory where the command is run. I added the attempted parse location to session.log:

02/09/22 12:04:16, =====================================
02/09/22 12:04:16, System/Build Info: 
02/09/22 12:04:16, YAFU Version 2.08
02/09/22 12:04:16, Built with Microsoft Visual Studio  1922
02/09/22 12:04:16, Using GMP-ECM 7.0.4, Powered by MPIR 3.0.0
02/09/22 12:04:16, detected Intel(R) Xeon(R) Gold 5122 CPU @ 3.60GHz
detected L1 = 32768 bytes, L2 = 17301504 bytes, CL = 64 bytes
02/09/22 12:04:16, using 1 random witness for Rabin-Miller PRP checks
02/09/22 12:04:16, Cached 664579 primes: max prime is 9999991
02/09/22 12:04:16, Parsed yafu.ini from H:\src\c\yafu

Thank you.