[Martyn Sherriff]

Hello David,

I tried the the instructions from #28 and got the same error.
However I then uninstalled and reinstalled Julia and the associated Stata programs and it now works - no idea why!

Many thanks.
Martyn

[qing xuan]

Hello David,

I tried the the instructions from #28 and got the same error.
However I then uninstalled and reinstalled Julia and the associated Stata programs and it now works - no idea why!

Many thanks.
Martyn

I ran the example you mentioned, and everything works fine on my computer.
Perhaps you can refer to:
https://zhuanlan.zhihu.com/p/671283299
(Translated using Google Translate)

[Manav Raj]

Hi David Roodman ,

Thanks for producing this tool! I just tried to install and run this and I'm getting an error when I try and run models with interaction effects.

I'm trying to run a continuous DiD specification that seeks to measure how bidding activity by freelancers on an online platform changes following a discontinuous shock depending on freelancer exposure to the shock. My main specification looks like the following:

reghdfejl ln_bids c.exposure##i.post, absorb(date id) cluster(id)

When I run this model, I'm receiving the error, "factor-variable and time-series operators not allowed". The model seems to run without an issue if I switch to reghdfe. Further, reghdfejl seems to work okay if I include purely continuous variables or factor variables without the interaction.

I am using version 0.6.1 of reghdfejl, version 6.12.3 of reghdfe, and version 0.9.0 of jl (I think all should be up to date). I've tried restarting STATA to see if this may resolve the issue but haven't had luck with that. Do you have any ideas for how I could troubleshoot this?

Thanks in advance for any help,
Manav

[David Roodman]

Thanks for the bug report Manav, and sorry for the trouble.

I've got a new versions of reghdfejl and jl pending for SSC. For now, can you try installing from GitHub and let me know if they help? You must install the two together.

net install reghdfejl, replace from(https://raw.github.com/droodman/reghdfejl/v0.6.2)
net install julia, replace from(https://raw.github.com/droodman/julia.ado/v0.10.0)

And maybe restart Stata after these commands finish.

[David Roodman]

Update: latest versions are now on SSC. So install with

ssc install reghdfejl, replace
ssc install julia, replace

[Sterling White]

Hi David,

I installed Julia on my Mac (M2 Pro) using the latest stable version (v 1.10.2). I am able to launch Julia through the terminal window by typing julia. However, when I try the test commands in Stata, I get an error: "Can't access Julia. jl requires that Julia be installed and that you are able to start it by typing "julia" in a terminal window (though you won't normally need to)."

I tried to uninstall and reinstall the julia package (v 0.10.1) from SSC. Do you have any suggestions?

Thanks,
Sterling

[David Roodman]

Mmmm... Sterling White, can you start a log, do "set trace on", try a test command again, and send me the log? My email address is in the help file.

[Roman Wang]

Hi David Roodman ,

Great package! Thanks a lot! I encountered the same issue as Manav Raj. I solved it by running

net install reghdfejl, replace from(https://raw.github.com/droodman/reghdfejl/v0.6.2)
net install julia, replace from(https://raw.github.com/droodman/julia.ado/v0.10.0)

and

ssc install reghdfejl, replace
ssc install julia, replace

However, there might be a memory-leak type issue? As I run more and more regressions with reghdfejl (with ##), the RAM consumption increases monotonically. I tried "clear" everything, but did not release any RAM usage. Only way to release RAM is to close STATA. I'm very new to Julia, btw.

Thanks a lot in advance.

[David Roodman]

Hi Roman Wang. There *is* a memory leak in version 0.10.0 of the julia package, which you seem to be using sometimes. The latest version is on SSC, so use that. It's actually 0.10.2, but I forgot to bump the version number at the top of jl.ado, so "which jl" says 0.10.1.

[David Roodman]

Sterling White , the latest version of the julia package on SSC, 0.10.3, fixes a bug that might be the source of your problem.

[Sterling White]

Thanks, David Roodman. I updated to jl 0.10.3, restarted Stata, and unfortunately am still getting the same error message.

[Petter Berg]

Hi David,

Thank you so much for this package! It runs so fast compared to reghdfe and is a lifesaver in my current project.

However, I have found what is potentially a bug, or something that works in a way that I don't understand. This occurs when including multiple variables in the absorb option, using wildcards (such as *).

See the example below. Describing the variables to be absorbed shows that they are named abs1, abs2 and abs3. Running reghdfejl absorbing these as "abs*" produces very different results than including them individually. The second example corresponds perfectly to reghdfe, and should be correct.

It would be very helpful to be able to use wildcards in the absorb command!

Best,
Petter

[David Roodman]

Oh interesting, thanks.
I have pushed out new versions of the julia and reghdfejl packages that I think, among other things, fix this issue. For now, they are only on GitHub. Install with:

net install julia, replace from(https://raw.github.com/droodman/julia.ado/v1.0.0)
net install reghdfejl, replace from(https://raw.github.com/droodman/reghdfejl/v1.0.0)
​​​​​​​

[Nikhil Datta]

Hi David

Thanks a lot for developing this. I've been running some baseline tests and have a quick qu.

OS Windows 10  Enterprise 64-bit
RAM 64gb
CPU 12th Gen Intel Core i9-12900K, 16 Cores, 24 Logical Processors

I set the environment variable so Julia is always started with 23 threads and ran it before any of the below so it had been compiled.

t=301 //  reghdfe
t=100 //  reghdfejl, (default threads = 23)
t=102 //  reghdfejl, threads(16)
t=106 //  reghdfejl, threads(4)
t=107 //  reghdfejl, threads(1)

I was quite surprised to essentially no difference when increase threads. When running any of the above and I check the cpu usage in resource monitor it doesn't exceed 17%, which is suggestive it isn't using all cores- I would have assumed to see it peak considerably higher (maybe this is my ignorance)?

To double check that the default is 23 threads:

.
jl: Threads.nthreads()
23

Do you have any suggestions what might be up?
Thanks!

[David Roodman]

A preliminary response: as I think it says in the help file, a good guess for the optimal number of threads is the number of performance cores on the CPU, which here I think is 8. They are hyperthreaded to appear to the OS like 16 cores. The other 8 are slower "efficiency" cores. So all that is only to say I wouldn't expect much improvement in going from 8 to 23.

You might try adding the -verbose- option. This will display the Julia regression command and the data set, and leave the data set behind in Julia, in "df". So then you can rerun it with jl: commands and experiment with the nthreads option of the reg() function that is doing the estimation. If you get the same behavior, then it's really a question for the maintainer of FixedEffectModels.jl. In my experience the package benefits less form multithreading when average FE group size is very small.

Example, with some output omitted:

. sysuse auto

. set rmsg on

. reghdfejl price weight length, absorb(rep78) verbose threads(2)
f = @formula(price ~ weight + length  + fe( rep78 ))
reg(df, f      , nthreads = 2     , maxiter=16000, contrasts=Dict{Symbol, DummyCoding}(  ))

jl: reg(df, f      , nthreads = 2     , maxiter=16000, contrasts=Dict{Symbol, DummyCoding}(  ))

jl: reg(df, f, nthreads = 2)
                            FixedEffectModel                            
=========================================================================
Number of obs:                   69   Converged:                     true
dof (model):                      2   dof (residuals):                 63
R²:                           0.434   R² adjusted:                  0.379
F-statistic:                22.9848   P-value:                      0.000
R² within:                    0.426   Iterations:                       1
=========================================================================
          Estimate  Std. Error    t-stat  Pr(>|t|)   Lower 95%  Upper 95%
─────────────────────────────────────────────────────────────────────────
weight     5.47831     1.15858   4.72846    <1e-04     3.16307    7.79355
length  -109.507      39.261    -2.78919    0.0070  -187.963    -31.0496
=========================================================================

(The last command line drops two options that are programmatically generated but aren't doing anything.)