How to calculate velocity for a shorter than normal sprint?

I try not to overcomplicate it, as story points are just a guess in the world of complexity. Just take two-thirds of the average Product Backlog completed from past Sprints.

Velocity is empirical data from past Sprints, and measures the amount of Product Backlog the team can turn into a valuable, useful, 'done' product Increment. If a team doesn't have anything 'done' by the end of the Sprint, then the velocity for that Sprint is actually ZERO.

Here's the official definition from the Scrum Guide.

Velocity: an optional but often used indication of the amount of Product Backlog turned into an Increment of product during a Sprint. It is tracked by the Developers for use within the Scrum Team.

Agree with the approach suggested by @Chris, for the initial sprint planning you may consider the velocity as suggested. More than story points the focus should be on delivering a Done, valuable increment and the end of the sprint. Focus also should be on individual stories and tasks as you might have to break them down further. Let at least 3 sprints go by and then inspect and adapt accordingly.

My company works in 3-week sprints, but due to scheduling issues and PI planning we recently had a 2-week sprint. How can I calculate the velocity of the sprint to account for the fact it was a shorter time period? 

Unless you are going into Sprint Planning with the genuine, serious, honest-to-God intention of creating & using at least one Done Increment no later than the end, you don't have a Sprint at all. Should business conditions change rapidly then you don't have to put it to use, but it's your intentions in Sprint Planning that count.

If company scheduling & planning issues are impediments to achieving Done each Sprint, then you can assume velocity is zero, zip, zilch, nada, nothing.

Everything that has been said previously echoes my thoughts.  Especially @Ian's.  

I am also going to say that the fact you have a formula for calculating velocity based upon guesses is somewhat disturbing. Velocity isn't the rate at which you guess you can get work done.  It is the rate at which you actually do work.  If your organization is so advanced to need PI planning, then they should be using something more advanced to calculate the rate at which work is done.  I suggest flow metrics. But I digress. Let me get back to giving you an answer to your question.

How can I calculate the velocity of the sprint to account for the fact it was a shorter time period? 

Since your formula does not use any value related to the length of the sprint, it should be just fine to use the same formula.  The shorter time period isn't relevant.  Your velocity is going to be a whole number. So you have one number that is less than all of the others.  It isn't going to significantly impact the team's ability to use the numbers. In fact, it could be useful to them to see how they complete work across the span of a sprint. "We usually complete ## points each 3 week sprint. But in a 2 week sprint we completed ## points. What does that say about our work distribution across a sprint?"

So, velocity is a measure of the actual work completed, not just what you could potentially achieve. The key focus should be on planning what deliverable increment you can produce in the 2-week sprint. In the end, you'll be able to compare the velocity of both 3-week and 2-week sprints to gain insights into your team's performance and efficiency.