w4kek/WSJT-X
1
0
Fork 0
mirror of https://github.com/saitohirga/WSJT-X.git synced 2024-11-03 16:01:18 -05:00
Code Issues Packages Projects Releases Wiki Activity
94472ac31c
WSJT-X/lib/decoder.f90

81 lines
1.8 KiB
Fortran
Raw Normal View History

Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
subroutine decoder(ss,id2)
use prog_args
include 'constants.f90'
real ss(184,NSMAX)
character*20 datetime
logical done65,baddata
integer*2 id2(NTMAX*12000)
real*4 dd(NTMAX*12000)
common/npar/nutc,ndiskdat,ntrperiod,nfqso,newdat,npts8,nfa,nfsplit,nfb, &
ntol,kin,nzhsym,nsave,nagain,ndepth,ntxmode,nmode,datetime
common/tracer/limtrace,lu
save
nfreqs0=0
nfreqs1=0
ndecodes0=0
ndecodes1=0
if (nagain .eq. 0) then
Take advantage of the new KVASD v1.12 Pass the temporary directory to jt9 and use it to give the correct paths to temporary files. Also jt9 passes the absolute path to kvasd.dat in the temporary directory to kvasd. Clear out all the annoying cruft that has accumulated due to having to run with $CWD as the temporary directory. Use QStandardPaths to find the writable data directory where needed rather than passing it around between objects. This now works because the $CWD hasn't been changed. Do away with the CMake option WSJT_STANDARD_FILE_LOCATIONS as it is no longer needed. Fix astro status file azel.dat formatting. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4732 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-12-02 19:06:54 -05:00
open(13,file=trim(temp_dir)//'/decoded.txt',status='unknown')
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
else
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
open(13,file=trim(temp_dir)//'/decoded.txt',status='unknown', &
position='append')
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
end if
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
open(22,file=trim(temp_dir)//'/kvasd.dat',access='direct',recl=1024, &
status='unknown')
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
npts65=52*12000
if(baddata(id2,npts65)) then
nsynced=0
ndecoded=0
go to 800
endif
ntol65=20
done65=.false.
if((nmode.eq.65 .or. nmode.eq.65+9) .and. ntxmode.eq.65) then
Always allow JT65 decoding above the blue line, when in JT9+JT65 mode. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4198 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-07-09 08:58:12 -04:00
! We're decoding JT65, and should do this mode first
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
if(newdat.ne.0) dd(1:npts65)=id2(1:npts65)
nf1=nfa
nf2=nfb
call jt65a(dd,npts65,newdat,nutc,nf1,nf2,nfqso,ntol65,nagain,ndecoded)
done65=.true.
endif
if(nmode.eq.65) go to 800
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
! print*,'A'
!!$OMP PARALLEL PRIVATE(id)
!!$OMP SECTIONS
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
!!$OMP SECTION
! print*,'B'
call decjt9(ss,id2,nutc,nfqso,newdat,npts8,nfa,nfsplit,nfb,ntol,nzhsym, &
nagain,ndepth,nmode)
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
!!$OMP SECTION
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
if(nmode.ge.65 .and. (.not.done65)) then
if(newdat.ne.0) dd(1:npts65)=id2(1:npts65)
nf1=nfa
nf2=nfb
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
! print*,'C'
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
call jt65a(dd,npts65,newdat,nutc,nf1,nf2,nfqso,ntol65,nagain,ndecoded)
endif
Many changes in program jt9[.exe] aimed at speeding up the decoders. The long FFTs can now use the multi-threaded FFTW routines. Subroutine decode9.f90 was renamed jt9fano.f90. The JT9 decoder's top-level functions were removed from decoder.f90 and put into a separate subroutine decjt90.f90. Subroutine decoder.f90 is now configured for possible use of OpenMP SECTIONS, with the JT9 and JT65 decoders running concurrently on a multi-core machine. Note, however, that this concurrent processing is not yet fully implemented. Probably calls to timer need to be removed; some variables used in calls to jt65a and decjt9 may need to be declared PRIVATE in decoder; some sections probably need to be declared CRITICAL; probably some SAVE statements in downstream routines have made them not thread-safe; etc., etc. I'm a neophyte at using OpenMP. Comments, suggestions, and/or tests by others will be welcome! git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4919 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2015-02-01 11:23:36 -05:00
!!$OMP END SECTIONS NOWAIT
!!$OMP END PARALLEL
! print*,'D'
Optimizations of JT9 and JT65 decoders; change clock in timer routine. Both decoders now have slightly better performance and faster execution. The rare "duplicate decodes" in JT9 were eliminated. On Windows, at least, calls to f90 routine system_clock() do not provide correct wall time increments. Changed to using secnds() instead. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4571 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-10-30 15:29:16 -04:00
! JT65 is not yet producing info for nsynced, ndecoded.
Open decoded.txt in append mode when redoing a decode pass. Before the subsequent decodes on a period (nagain/=0) were truncating the file and confusing JTAlert. git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@4047 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
2014-04-19 22:44:47 -04:00
800 write(*,1010) nsynced,ndecoded
1010 format('<DecodeFinished>',2i4)
call flush(6)
close(13)
close(22)
return
end subroutine decoder
Reference in New Issue Copy Permalink